Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 10

Thread: OpenGL SC

  1. #1
    Junior Member Newbie
    Join Date
    Mar 2013
    Posts
    5

    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.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,117
    You will need a regular grid then you can look at things like ROAM ( http://en.wikipedia.org/wiki/ROAM )

  3. #3
    Junior Member Newbie
    Join Date
    Mar 2013
    Posts
    5
    Quote Originally Posted by tonyo_au View Post
    You will need a regular grid then you can look at things like ROAM
    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

  4. #4
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,136
    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?

  5. #5
    Junior Member Newbie
    Join Date
    Mar 2013
    Posts
    5
    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.

  6. #6
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,136
    It is odd that glDeleteLists() is not supported. Excuse for that seems not quite clear.
    Quote Originally Posted by OpenGL Safety-Critical Specification Version 1.0.1 pg.30
    Desktop OpenGL includes DeleteLists to allow complex applications to reclaim display list memory at run-time. However, implementing DeleteLists requires "real" memory management for handling the display list names, adding a burden to the driver implementation. Also, it is difficult to implement compacting or garbage-collection while respecting real-time constraints. Current safety-critical applications rarely call DeleteLists, it is therefore feasible to omit DeleteLists and to push the memory management issues from the driver to the application. Inclusion of DeleteLists or a replacement with similar functionality will be considered for 1.1.
    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.

  7. #7
    Junior Member Newbie
    Join Date
    Mar 2013
    Posts
    5
    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/...e/#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.

  8. #8
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,136
    Quote Originally Posted by fear4ever View Post
    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.
    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 Originally Posted by fear4ever View Post
    Sorry for not being more clear on geomclipmap subject. This is the link for it
    http://research.microsoft.com/en-us/...e/#geomclipmap
    See Geometry clipmaps: Terrain rendering using nested regular grids.
    I haven't understand your question that way. Geometry clipmaps is a very well known algorithm with many variations.

    Quote Originally Posted by fear4ever View Post
    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.
    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.

  9. #9
    Junior Member Newbie
    Join Date
    Mar 2013
    Posts
    5
    Quote Originally Posted by Aleksandar View Post
    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.
    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 Originally Posted by Aleksandar View Post
    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.
    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" ?

  10. #10
    Newbie Newbie
    Join Date
    Jul 2012
    Location
    n/a
    Posts
    2
    Thanks for that topic, I find it very interesting.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •