OpenGL SC

Hello,

I was wondering, if one wanted to develop a terrain rendering system for large areas (wont fit in memory) but were limited by both driver api and hardware, what would be the best method/algorithm to use?
Assume OpenGL 1.3 (see OpenGL SC 1.0.1) and 5-10 years old hardware (CPU/RAM/GPU).

Obviously any shader implementation is out of question. Even old constructs like VBOs are not allowed but we can use vertex/display lists.

You will need a regular grid then you can look at things like ROAM ( ROAM - Wikipedia )

Thank you for the interest tonyu. I am aware of the various algorithms available, vterrain.org makes a nice list of them too. I have also partly or fully implemented some of them in windows in the past
Correct me if i am wrong, to my knowledge ROAM is quite CPU intensive. I think an algorithm that saturates the graphics pipeline while putting the least strain on CPU would be more suitable.
Any insight from people with practical experience would be greatly appriciatetd

ROAM is really outdated algorithm, but since you are confined to GL 1.3 there is no many choices.
If the viewer is relatively statical than display lists are the best choice. Just divide terrain into tiles and make a DL for each tile. While you are inside boundary of a single tile, nothing changes and you have highest possible frame rate. When you pass the border of a tile, reorganize tiles. I used such approach many years ago. The only problem with DLs is that you cannot refill them, just destroy and recreate. It costs. Instead of DL, you could use vertex arrays. The frame-rate will be lower, but refilling is smoother. You could also try any of the algorithms that use VBOs, but change them with VAs. My favorite is a clipmap approach, but somewhat changed (the combination of clipmaps and tiles).

By the way, where did you find GL SC implementation and for what platform?

OpenGL SC not only limits APIcalls to GL 1.3 but removes some from that subset too. glDeleteList being one of them. Vertex arrays seem like the best option to me too. VBOs are still out of question.
Would not geoclipmap approach work netter here? Regular multi-resolution meshes that can optimized to target hardware performance so as to find a balance between performance and precision/resolution? I read Hoppe’s original paper but i find the explanations lacking in detail and cant find any sample implementation.

GL SC implementation i don’t have personally, but it can be obtained from some specialized vendors targeting safety critical markets.

It is odd that glDeleteLists() is not supported. Excuse for that seems not quite clear.

I’m not sure what you meant with a “regular multi-resolution meshes”. You should post a link to the paper in order to have any comment.

Lacking support for delete operation is to do with memory usage. Some standards that have to be observed while developing SC applications require that no dynamic memory allocation ever takes place.

Sorry for not being more clear on geomclipmap subject. This is the link for it
http://research.microsoft.com/en-us/um/people/hoppe/#geomclipmap
See Geometry clipmaps: Terrain rendering using nested regular grids.

The way i understand it is that there are several iso-centric grids with varying resolutions and sizes in a pyramid structure with the highest resolution grid being on the top.
It seems that implementation would require a static memory allocation for all the grids and not require additional memory for loading/unloading tiles etc.

What’s happening when you call glNewList() for the ID already used? I guess it will delete previously allocated list and create new one with the same ID. If it is not the case, the implementation is clumsy. Otherwise, you have a way to manage execution of any algorithm with DLs.

[QUOTE=fear4ever;1249018]Sorry for not being more clear on geomclipmap subject. This is the link for it
http://research.microsoft.com/en-us/um/people/hoppe/#geomclipmap
See Geometry clipmaps: Terrain rendering using nested regular grids.[/QUOTE]
I haven’t understand your question that way. Geometry clipmaps is a very well known algorithm with many variations.

[QUOTE=fear4ever;1249018]The way i understand it is that there are several iso-centric grids with varying resolutions and sizes in a pyramid structure with the highest resolution grid being on the top.
It seems that implementation would require a static memory allocation for all the grids and not require additional memory for loading/unloading tiles etc.[/QUOTE]
The sizes of the grids are equal, but the resolution changes (2x with each level, and the grids have to be aligned; I’ll try to remove that constraint, but it would be not regular clipmaps approach). Memory allocation doesn’t change, but in the classical approach you have to update index buffer in every frame. It shouldn’t be the problem to implement it using VAs, although the frame-rate will be probably unacceptable low. That’s why I used DLs and divided layers into equal-size tiles. I have abandon that approach since the transition between blocks is not fluent, but it is still extremely fast for the ancient hardware and limited movements.

It seems from the description that glDeleteList is not a asub call in glNewList. I dont have a deeper knowledge in the driver implementation part. It is just a given that glDeleteList cannot be used. If calls on glNewList on the same id is not prohibited that may be the way to go.

[QUOTE=Aleksandar;1249204]I haven’t understand your question that way. Geometry clipmaps is a very well known algorithm with many variations.

The sizes of the grids are equal, but the resolution changes (2x with each level, and the grids have to be aligned; I’ll try to remove that constraint, but it would be not regular clipmaps approach). Memory allocation doesn’t change, but in the classical approach you have to update index buffer in every frame. It shouldn’t be the problem to implement it using VAs, although the frame-rate will be probably unacceptable low. That’s why I used DLs and divided layers into equal-size tiles. I have abandon that approach since the transition between blocks is not fluent, but it is still extremely fast for the ancient hardware and limited movements.[/QUOTE]

That is what i had in mind when i said “Regular multi-resolution meshes”.
Guess i’ll give it a try when i have the time to DL approach. Thanks Aleksandar.

Anyone has a link to any implementation of “Geometry clipmaps: Terrain rendering using nested regular grids” ?

Thanks for that topic, I find it very interesting.