posted January 10, 2000 12:27 PM
This is a continuation of the conversation begun in the thread "Quicker bintri tree rendering?". Seumas has been helping me with some ideas on implementing large terrain set support for a ROAM-type engine. If you are interested in this topic, be sure to check the original thread to catch the beginning of the conversation.
In Reply to Seumas' Jan 09 post:
Well, you've motivated me to get off my butt and pull out the calculator. Up to this point it's been mostly a thought project, but now with an engine to support it I ought to take the next step.
Here's what I came up with.. A standard set of 4 mip-map levels for height field data (256, 128, 64, & 32 units square). Also 4 corresponding patch classes (each taking up the same 256x256 amount of world coordinates, but mapping to the 4 mip-map levels thus giving less resolution in the distance). And aprox 1 Km view distance and a unit resolution of 16 cm.
The viewable landscape would be an array of patches. Mip level 1 is the center  of them. Surrounding that would be a border of 6 patches at mip level 2, followed by 6 at mip level 3 and another six at mip level 4. Thus from the eye in the center, one would see across 24 patches to the far clipping plane. 24 patches * 256 units * .16 meters = 983 meters (across the short dimention of a patch).
This set of height fields would requre:
mip level 1: 12*12 patches @ 256x256 bytes = 9,437,184 bytes
mip level 2: 432 patches @ 128x128 bytes = 7,077,888 bytes
mip level 3: Well.. It's already too high, so I'll stop here.
My guess for Tread Marks is:
16^2 patches @ 64x64 bytes = 1,048,576 bytes at 1 Km view distance.
The suggestion about triangle sizes is new to me, I've not encountered that before. I remember reading something similar from Quake, triangles which took less than a certain screen area were plotted as three pixels instead of rendering the whole triangle. Time to get back in the code and see where those triangles start getting too small.
Thus my desire for finding a way to evaluate the fractal and apply a difference map to it on the fly & saving many megs of RAM. Now that I've got my graph paper out (handy stuff that), I can understand your method. I'll pull out my old design docs and see why it was that I moved to the more complex method... (Spock says: It seemed logical at the time!)
BTW: I'm trying to understand the GL matrix stacks, and can't get the calculation right to check for visibility in the frustum. I load the frustum on the projection stack, then do I move to the model stack and transform the patch? How do I compare this to the projection stack entry?