Methods to boost rendering speed - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: Methods to boost rendering speed (/thread-3850.html)
Methods to boost rendering speed - Jones - Sep 26, 2006 03:14 PM
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.
EDIT: The word r-e-t-a-r-d-e-d is blocked?
Methods to boost rendering speed - akb825 - Sep 26, 2006 03:36 PM
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.
Methods to boost rendering speed - Jones - Sep 26, 2006 03:43 PM
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.
Methods to boost rendering speed - akb825 - Sep 26, 2006 03:45 PM
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.
Methods to boost rendering speed - Jones - Sep 26, 2006 04:15 PM
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.
Methods to boost rendering speed - OneSadCookie - Sep 26, 2006 04:35 PM
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
Methods to boost rendering speed - Jones - Sep 26, 2006 04:51 PM
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. )
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.
Methods to boost rendering speed - akb825 - Sep 26, 2006 05:04 PM
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.
Methods to boost rendering speed - PowerMacX - Sep 26, 2006 08:04 PM
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.
Methods to boost rendering speed - unknown - Sep 27, 2006 04:41 AM
PowerMacX Wrote:Something like ROAM is terribly inefficient nowadays.
Methods to boost rendering speed - OneSadCookie - Sep 27, 2006 05:22 AM
because when ROAM was designed, CPUs were fast and GPUs were slow. These days, it's the other way around.
Methods to boost rendering speed - TomorrowPlusX - Sep 27, 2006 05:25 AM
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.
Methods to boost rendering speed - PowerMacX - Sep 27, 2006 05:33 AM
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
[edit: You guys type too fast!]
Methods to boost rendering speed - TomorrowPlusX - Sep 27, 2006 08:32 AM
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
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.
Methods to boost rendering speed - PowerMacX - Sep 27, 2006 12:10 PM
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):
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).