Horde3D

Hi all,

I've just been thinking, could the terrain extension be adapted to support something along the lines of vector displacement mapping? I'm not sure what the CPU overhead would be to regenerate the VBOs or if this would even work with the current LOD system and skirting, I'm sure there would be glitches of sorts. I think the mainstream format of vector displacement is 3 channel vectors encoded into a 16/32bit per channel format, but I'm wondering if it's possible to just have 2 8-bit channels for the displacement weighting (RG having coarse+finer for effective 16-bit displacement) and 2 8-bit channels for the XY normal direction in BA like the current format of terrains in the terrain extension...

Opinions? Bad idea?

_________________
-Alex
Website

It's possible. (If you haven't watched the Halo Wars terrain video ... it's worth the time)

I would go ahead and give it a try. You'd only have to fuss with TerrainNode::_heightData and the code around line 153 of terrain.cpp to get it drawing (with quirky AABBs). Though then you'd have to go through and adapt all the intersection, and AABB stuff after you've decided whether to commit to it or not.

If I'm understanding you correctly, you intend to displace along the direction of the surface normal? If so, couldn't that lead to normals that aren't correct (ie pointing along the surface of a slope rather than out and away from it)?

Thanks AcidFaucet, I remember watching this talk before but I forgot what game it was for (whoops).

I think I won't do it for vertex texture fetch but just use the cpu + indices tweak while still retaining the same VBO blocks that the current Horde3D terrain extension does, but the 11,11,10 32-bit format interests me. I'm just trying to work out what texture format would store this, possibly with PNG-like compression (custom format perhaps). 16-bit per vertex direction is a little bit too much, I think 11,11,10 would be enough...

Yeah displace along the surface normal, but the normal being derived from the pixel with the weight being the 16-bit signed height or "weight" map. The Z direction would be derived from the weight map's + or - and the 8-bit X,Y would be the tangent direction of it based from the flat uniform grid. Maybe I'm not understanding this fully... Perhaps just storing the direction in world space (like vector displacement maps from mudbox/xnormal) would be a lot easier and the actual normals in a separate texture like what Halo Wars did.

_________________
-Alex
Website

I really think that your biggest issue is going to be what to do with the skirts of the terrain. If you grow a crooked spike out of the terrain it may be in just the right place for the skirt to be sticking out. Perhaps you could test for that during the init, or maybe it'll turn out to just be boundary cases.

Watching the halo wars talk again I notice that they were much more concerned with the geometry in regards to efficiency than anything else.

Also, thinking ahead, it'd probably be easier to deal with "pelt" adjustments like 'relaxing' in the 3 component world where it's all very intuitive rather than working with normals and displacements. Or at least start there so you can make comparisons.

I'm certain you could do it, but I myself don't see much of a time invested vs. performance benefit out of displacing off a normal vs. raw offsets unless you're targeting low-end hardware like phones.