|
Author Topic:   Geomorphs?
assen
Member
posted October 05, 1999 04:23 AM            
Have you implemented geomorphs in the latest demo? I have observed some vertices change gradually their vertical position.

IP:

LDA Seumas
unregistered
posted October 05, 1999 11:56 AM           
Yes, Tread Marks has pretty much always had Vertex Morphing, or Geomorphs, for the terrain. Due to the way my geomorphs are completely stateless (the amount of morph is computed fresh each frame, and isn't based on time), the algorithm has some quirks, and once in a while you'll see a triangle pop or even oscillate, but most of the time things are smooth.

The latest test even has vertex morphing of sorts for the meshes. Notice how when your tank gets heavily damaged, it starts to crumple up and deform.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

assen
Member
posted October 05, 1999 12:24 PM            
So much for me hoping to get away without geomorphs I couldn't get it smooth at 1000 triangles with no amount of tweaking the priority computation formula. I thought you had mentioned somewhere you don't do geomorphs, but obviously I've been wrong...

Well Seumass, I guess there's only so much you can explain us, we should figure the vertex morphing by ourselves. Ideas anyone?

The morph should converge to the original vertex height when at maximum detail, and to the midpoint of the hypotenuse of one of the two possible pairs of triangles...

The tanks deformations are great. Overall, the design of the second demo is very excellent. Things like the animated cursor in the menu and the particle system in the background have been easy to code, but add a lot to the "wow" factor.

IP:

LDA Seumas
unregistered
posted October 05, 1999 01:00 PM           
Correct, the morph is between the interpolated center of the parent's hypotenuse, and the real height at that location. The amount of morph is calculated by making the split test a "fuzzy" test, rather than a binary test. The fuzziness is on the side of "split", rather than "not-split". Just as the variance crosses the "split" boundary, the morph is completely towards the interpolated height. As the variance gets further into the "split" region, the morph progresses towards the fully sampled (from the height map) height, until after a certain variance, the sampled height is always used.

So it's basically:

if(TriVariance > VarianceLimit){ //Split tri.
t = TriVariance - VarianceLimit;
if(t < MORPH_RANGE){ //Tri is morphing.
TriMorph = t / MORPH_RANGE;
}else{
TriMorph = 1.0; //Sampled height, no lerp.
}
}

Using floats for all those variables. And of course you wouldn't use a divide by MORPH_RANGE, but instead a multiply by a pre-calculated 1.0 / MORPH_RANGE.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

assen
Member
posted October 12, 1999 04:47 AM            
I can't get it to work...

I get cracks between adjacent tiles; the priorities of adjacent triangles across a tile boundary are different, even though they share the same midpoint-of-hypotenuse displacement error. I changed my priority formula to include _only_ this displacement error, but I still get cracks.

If you use for the triangle error what you cited in your article on BinTriTrees and tesselation:
Error = MAX(Displacement, Error(LeftChild), Error(RightChild) )

you will inevitably have different priorities for triangles across the tile boundary. How do you handle this? Do you use just the displacement for the morphs?

/*
BTW, the original ROAM computation goes more like this:

Error = Displacement + MAX(Error(LeftChild), Error(RightChild))

and in their context, wedgie thickness computation (the bounding prism of the triangle with it children) it makes more sense... anyway, this is not a big deal, I've found that this family of algorithms work to a certain degree with any priority computation formula you throw at them
*/

IP:

LDA Seumas
unregistered
posted October 16, 1999 09:57 PM           
Sorry about the delay.

I get around the problem of different "morph" values on either side of the line by averaging the two morph values and using that average for both sides. It adds a little complication, but I think the morphing is worth it.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP: