DirectX 11 tesselation and floating geometry in high poly models

EmAr

Hi! I was thinking about this yesterday. Now with real time tesselation available, we can use displacement maps in our materials. Floating geometry is not a problem for normal maps since the normals don't change if some floating high poly geometry is above(not too much of course) the base high poly geometry.

Now that displacement maps contain info about height differences, will it be necessary to model those small bits and bolts into our base high poly meshes or can we still use floating geometry within certain limits?

I'm asking this out of pure wonder, I don't have even a dx 11 graphics card but it would be nice to know Thanks for any information.

EarthQuake

Yes, you would either have to model it all in correct, or manually adjust the height map.

IMO, i dont see tessellation being all that advantageous to hard surface things like weapons or mechanical props, atleast not as much as characters and other things that will require more rounded silhouettes. So you may not have to worry about that too much.

Hell, in most cases i would probably rather just have a thousand or two extra tris to play with manually, than the messiness of automatic tessellation, but i really do not know how efficient it is in terms of rendering speed.

Eric Chadwick

Real-time displacement is a pain for artists, at least in my experience.

Traditional 8bit grayscale is only 256 levels of height, so you get banding. You want to use a higher bit depth, like 16bpp, but that kills your video memory. DXT compression really sucks too, can't use that for displacement, the errors are much more pronounced with displaced geom.

Displacement maps are also harder to edit than normal maps. The margin for error is much greater, since tiny differences in value create bigger visual errors. Can't easily overlay details either.

ZacD

there has been some floating geo in the 2 dx11 demos I've seen, rocks intersecting the ground, and windows and rocks on the corners of buildings, I think most places where bolts and nuts are going to be used aren't going to be rough, but smooth, and wouldn't have tessellation on them in the first place. But I think it would be fairly easy to "paint" on the displacement map to make sure the geo wont intersect floaters.

Eric Chadwick

Right, but I think EmAr meant floating geo for the bake, like you would use for normal map bakes.

ZacD

Damn my skimming reading, I'm sure the work flow will change, I'd like to see how well floating detail and basically flat details work with tessellation.

r_fletch_r

Slightly off topic but doesnt this dx11 tesselation open the way for real time Catmull Clark SDS in games/3D Apps, its just a different tesselation program right?. The impact this could make to 3D apps is pretty jaw dropping

arrangemonk

@bonding, one could save one 32 bit integer for heigt splitted into the rgba channels of the map, that way it can be compressed but i dont know it it gives good results, but it would have more precision than an 8 bit displacement map and can be saved in dxt compression , and doesnt kill your video memory since the map is compressed and the height is calculated with 3 shift operations and 3 additions

Eric Chadwick

Hey that's a good idea, splitting 32bpp into four 8bpp channels!

Not sure that would work in DXT though, the 4x4 block artifacting is pretty bad. And it would be even worse since you would be storing a totally different grayscale range in each channel... at least the way NVIDIA compresses them, it's built to minimize errors working on photograph-like source, where the 3 channels are fairly similar.

r_fletch_r

are the displacement maps going to need to be that high res? id imagine you could get a lot done silhouette wise with a relatively low res map. i mea this isnt going to replace normal maps for fine detail is it?

SHEPEIRO

that depends on the engine... i presume if the tesselation is down to near per pixel then yes there would be no need for normal mapping, but im guessing at any less than that it would have to be accompanied by it, the res has to be high enough, say your working at 8 pixels per triangle screen space (thats what that demo in P&P was using right), then i guess you can get away with 8 times less texture space than your normals, if you were aiming for a rough 1 texture pixel for 1 screen pixel

if the hightmaps were added as a normals alpha, could you read every block of 4x4 or 8x8 pixels as one to get a higher value range...