• 11/03/03 12:27 AM
    Sign in to follow this  

    Super Frustums

    Graphics and GPU Programming

    Myopic Rhino

    1. Introduction
    When managing access to very large terrain extensions it becomes absolutely necessary to tile the terrain so that it can be dynamically loaded/unloaded with a separate thread. That way, the memory size isn't a limitation any more (it's only a limitation to the terrain that is intended to be rendered in every frame, not to the terrain that can be handled).

    Some obvious approaches have been used, but, as far as we know, no approach has been proven to be as efficient as the one we will present here: the super frustum.

    We'll discuss in this article three different techniques to decide which terrain zone should be loaded.


    1.1. Algorithm evaluation
    In order to decide if an algorithm is good or not we've chosen three criteria:

    1. Adaptability to what we really need to be loaded (the view frustum): the better the loaded terrain zone adapts to the view frustum the less memory resources will be needed and the less data will have to be loaded from disk to memory.
    2. Data transfers between disk and memory: for each configuration change, we'd like to transfer the least possible data. This is a very important thing because it will determine the overall speed of the loader thread.
    3. The risk of desynchronizing the loading and the drawing processes. If the loading thread is slower than the movement of the camera, some cells might not be displayed though they could be inside the view frustum.

    2. Algorithms

    2.1 Rectangular matrix around the viewpoint.
    This is the approach described by Renato Bruno Pajarola in "Access to large scale Terrain and Image Databases in Geoinformation Systems", and, as we will prove, it's the worst one in the terms we have described.

    The approach is basically to keep loaded in memory all the cells that are less than sizeX in the X axis and sizeY in the Y axis from the cell the viewpoint is in.

    image001.jpg

    Adaptability to the view frustum:
    Very poor. It only considers the camera position, not the angles of it, so it implies lots of unused cells in memory.

    Leads us to draw only the 15-25% of what is loaded.

    Data transfers between disk and memory:
    Very high. Every time the camera moves from one cell to another, Xsize or Ysize cells must be loaded.

    Risk of desynchronizing the loading and the drawing processes:
    Not very high if the load of each cell is fast enough to handle position changes (the camera orientation changes won't give us any problem).


    2.2 Rectangular matrix containing the frustum projection on the y=0 plane.
    This algorithm is really a variation of the previous one. The limits of the matrix are determined by the points (xmin,ymin) and (xmax,ymax), which are calculated from the cells containing the projections of the frustum's 3 points (although it has 8 points, it can be approximated with 3).

    As a little improvement, security borders can be defined in both X and Y axis, to prevent the camera moving faster than the loader thread loads when turning the viewpoint.

    image002.gif

    Adaptability to the view frustum:
    Medium. With no security margins, about 60% of what we have in memory is inside the view frustum.

    Data transfers between disk and memory:
    It's been reduced to half of what we had with the previous algorithm.

    Risk of desynchronizing the loading and the drawing processes:
    Higher than the previous one. Orientation changes could produce desynchronization if we don't use appropriate borders.


    2.3 Super Frustum
    This is in our opinion the optimum solution to the problem we are dealing with.

    We will define a Super Frustum as a geometric entity that contains the frustum and that introduces some extra space that gives us an efficient way to pre-fetch terrain tiles.

    A Super Frustum can be 2D (defined by a triangle that contains the frustum's 2d projection) or 3D (defined by a pyramid similar to the frustum that contains the 8-point defined view frustum).

    This would be a 3D Super Frustum:

    image003.jpg

    The 2D version is not as accurate as the 3D one (some care must be taken with vertical pitch angles) but needs less CPU work. Both can be interesting depending on the particular application.

    In both cases, the Super Frustum can be fully parameterized depending on the system we are running on.

    image004.jpg

    Adaptability to the view frustum:
    Very high. We can achieve 85% use rates with enough security space.

    Data transfers between disk and memory:
    Low. It produces more configuration changes, but each one needs to load less cells, balancing the load/unload work

    Risk of desynchronizing the loading and the drawing processes:
    Low, because the load is very balanced, so every movement produces less loads/unloads.



      Report Article
    Sign in to follow this  


    User Feedback

    Create an account or sign in to leave a review

    You need to be a member in order to leave a review

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    There are no reviews to display.