Methods to boost rendering speed

Jones
Unregistered
 
Post: #1
I'm currently looking at display lists as a method to possibly boost drawing speed. When rendering a multi-frame model (like an md3 or md2) would it be beneficial to create a display list for every frame?

Hope this isn't a ******** question. Rasp

EDIT: The word r-e-t-a-r-d-e-d is blocked?

Thanks!
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #2
No. You would have to both draw and compile the display list every frame, which will likely be even slower than immediate mode. You should look at vertex arrays and VBOs for your solution.
Quote this message in a reply
Jones
Unregistered
 
Post: #3
Ah, thanks for the answer. I considered building big vertex arrays for my MD2 models, but I'd need one for every frame and they could not be compressed in memory the way I do it now.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #4
You don't need to make a new vertex array for each frame. All you need to do is change the values of each vertex.
Quote this message in a reply
Jones
Unregistered
 
Post: #5
akb825 Wrote:You don't need to make a new vertex array for each frame. All you need to do is change the values of each vertex.

Which would in turn take up CPU cycles. I lose both ways.

Although I am already unpacking compressed vertices every display cycle as is. Perhaps It would be better to un-compress my data into arrays before hand.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
if your application is running too slowly, use shark and other profiling tools to find the exact trouble spots before you waste lots of time optimizing things that aren't the problem. Chances are that you don't actually have a clue what's really slow Smile
Quote this message in a reply
Jones
Unregistered
 
Post: #7
Well nothing is running *too* slowly right now. But I have not yet tried dropping 20 models into a scene along with a terrain.

(My terrain code sucks horrendous amounts though, so I wouldn't do that until it's fixed. Rasp)

EDIT: Which is one of the reasons I made this post.

I figured it would be slow to dynamically scale down/up the the quality of the terrain based on camera position, so I'm looking for alternatives.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #8
I've been thinking of the same issues with terrain myself, though I won't implement them for a while. I think the most efficient way to update the terrain detail would be to have a certain range after an update where you can move before it recalculates.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #9
Er... I had way over 20 models running in my early tests with Okugai (basically, terrain+skybox+MD2s) at playable framerates... on my old 466MHz G4 with an ATI Rage 128Pro...

In any case, just make your terrain a display list (or composed of a few "patches", each a separate display list) and watch your FPS raise. Something like ROAM is terribly inefficient nowadays.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #10
PowerMacX Wrote:Something like ROAM is terribly inefficient nowadays.

Really, Why?

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #11
because when ROAM was designed, CPUs were fast and GPUs were slow. These days, it's the other way around.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #12
Because modern cards are so fast that you're best off with static geometry and clever culling/paging than uploading a unique geometry every frame.

In the 90's rendering was slow enough that the overhead of geenrating and uploading optimized geometry every frame was worth it. These days, it isn't.

I use completely static geometry -- generated from a heightmap using a ROAM-like algorithm -- but static once it's generated. I use a quadtree to cull the visible subset, where each leaf node has its geometry stored in a display list. When I iterate the tree to determine the visible set I build a list of lists, which I draw in one pass.

Works very nicely, drawing just the terrain and sky, I easily get 90 fps or so on my powerbook with a 5200.

EDIT: One more thing -- one ugliness with dynamic terrain LOD is that if you have an object on the terrain, a tank say, and the viewer pulls back, the tank can dissapear or float in the air depending on how the optimized terrain changes for the viewpoint.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #13
Well, you waste a lot of bandwith suffling vertices/normals/tex. coords. to the graphic card, which are a lot more powerful and intelligent nowadays, so they can optimize drawing by themselves, not rendering backward facing/obscured/out of frustrum polygons.

Implementing a patch-based, display-list cached terrain takes about 20 lines of code, so in any case I'd suggest evaulating that before getting into complex LOD algorithms devised when 3D graphics meant $ 10.000 worth of SGI equipment Wink

[edit: You guys type too fast!]
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #14
PowerMacX Wrote:Implementing a patch-based, display-list cached terrain takes about 20 lines of code, so in any case I'd suggest evaulating that before getting into complex LOD algorithms devised when 3D graphics meant $ 10.000 worth of SGI equipment Wink

[edit: You guys type too fast!]

20 lines!? My terrain class -- which admittedly has it's own specialized quadtree distinct from my scenegraph's -- is at least 1000 lines. Sure, my render function is only 30 or so, but generating the vertices, rendering patches to display lists, frustum culling via quadtree, setting up texturing, calculating lighting, etc etc, that's a lot of code.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #15
I wasn't talking about a nice implementation like yours, but about the most bare-bones one.

Basically (pseudo code, not on my mac right now):
Code:
void buildTerrainPatchList()
{
for (patchIndex=0;patchIndex < numPatches;patchIndex++)
{
     beginList(patchIndex);
     for (x=0;....)
     {
         for (y=0;...)
         {
             vertex
             ...
         }
     }
    endList
}

void renderTerrain()
{
    for (i=0;i<numPatches;i++)
        callList(i)
}

Frustrum culling is handled automatically (if roughly) by the graphic card (if no part of a patch lies inside the frustrum, it doesn't try to render the list at all).
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  what methods can't be used in display lists? ghettotek 9 4,112 Feb 9, 2003 12:47 PM
Last Post: OneSadCookie