|
Author Topic:   Help! Clutzy ROAM question
Andy
New Member
posted May 03, 2000 06:39 AM            
Hi - I'm new to this board... seems like a lot of people here are interested in terrain renderers. If there's anybody out there that can help:
I've written a ROAM-ish terrain viewer without geomorphing or frame coherence. Now I want to add these bits, and here lies the problem.
1) Geomorphing seems to presuppose frame-coherence (because a leaf node needs to store the interp. value over successive frames).
2) Frame-coherence requires global split and merge priotity queues, which means no patches(because a global queue will ignore patch boundaries). Frame coherence also means I can use the split queue alone for rendering, which means patch visibility checking is kind of redundant.
I'm going to do a complete rewrite to create the split-merge noodles without patches, but does anyone know a way I can integrate it the two?

IP:

Bryan T
Member
posted May 03, 2000 12:54 PM            
Andy,

Geomorphing does not require frame-coherence. Instead of a morph value in time, you can choose a morph value in distance.

That is, just after a split, the morph value should cause the new triangles to exactly overlap the old ones. There would be NO visible difference between the split and unsplit version.

Then as you came closer to the new split, but before it splits again, the morph value would cause the points to become closer to their actual location.

This method of morphing is perfectly acceptable in a split-only two-pass ROAM rendering engine. Now the actual details of getting it all to work are a different matter...

--Bryan

IP:

Andy
New Member
posted May 04, 2000 11:25 AM            
Cheers Bryan... doh! it seems so obvious after its been explained. Still, I haven't come up with a viable solution to the patch/split-merge problem. Using one seems to make the other mostly redundant, but both have useful properties that are unique to the method. btw you're interested in procedural techniques for large-scale terrains? I use several fractal procedural textures and a polynomial interpolating value to mix procedures over the heightfield (so one side might be a smooth multifractal, which will grow into a mountainous ridged multifractal in a realistic fashion). For non-fractal terrain features, i figure on using an RLE image to modulate the heights (non-modified heights being the runlength encoded value).... either that or a list of pre-generated terrain features that can be transformed and applied after the heightfield is generated. what do you think?

IP:

Bryan T
Member
posted May 04, 2000 01:27 PM            
Andy,

Split/Merge:
You lost me on that one.. What is the split/merge problem you are having? And which 'one' is making which other 'one' redundant?

The system of using a split/merge queue does not affect the rest of the system overall. You are able to use the queue for rendering (since it contains only leaf nodes), but you still must do the split/merge test on them. Is that what you are refering to as the visibility checking?

Patches are not redundant in the split/merge system either. If the system is setup correctly, remerging a bunch of triangles will end when it reaches the top level of a patch, thus preserving your patches.

Fractals:
Yes, I'm just now starting on fractal texture generation. Actually, per-pixel lighting is my problem currently...

As for adding non-fractal detail, your implementation sounds like it would work well. I was also examining such a scheme, but the problem I came to find was that the Bitmap you use to input non-fractal data has to be perfectly matched in height with your fractal. Otherwise you might have a mountainside with a perfectly square hole cut in it. At the bottom of the hole is your Bitmap heights. The hole bieng caused by a mis-alignment of the height of the fractal and your bitmap heights.

The pre-generated terrain features are good too, again, you need to make sure they get placed into the fractal terrain correctly. This is the scheme used by Tribes 2 to get rock bridges and caves, etc. But they're not working with fractal terrain either...

--Bryan

IP:

Andy
New Member
posted May 05, 2000 05:01 AM            
Hi Bryan.
Hmmmm - Now you mention it, I've lost exactly why I brought up the topic in the first place. I'm sure I had a good reason - I'll try and work it out:
Patch visibility checks mean that you can skip over both construction and rendering passes for a patch. This is good.
A global split-merge queue ignores patch boundaries. You would add all the base triangulations of the patches to the split queue initially and process away, but thats the last the patches would contribute. I guess you could set visibility flags all a patch's triangles if it went outside the view frustrum, but thats pretty contrived.
I think thats it. I've got a feeling I'm missing something out though...

IP: