display lists or vertex arrays
sometimes vertex arrays sometimes DL''s. dl''s are generally good for static objects that use a lot of statechanges eg 4 lights + multiple materials enabled
As far as performance, it depends on a variety of factors, i.e. the graphics card, the drivers, what you''re rendering, how you''re rendering it. You might find one to be faster than the other on your machine, only to find the reverse is true on another. In the long run, I''d opt to do what zedzeek says, use dl''s for static objects that require lots of state changes. That''s where you''ll usually get a big win, as the drivers have a lot of room to optimize whatever you throw into the dl.
Usually, display lists are good for all static geometry (wether including state changes or not). State changes by themselves can also be encapsulated in display lists, which will store them in a format optimized for the driver and make their execution faster.
Display lists are usually stored in AGP memory and faster than normal vertex arrays, but can''t be changed (unless you recompile them) and hence only viable for static meshes.
For dynamic geometry, vertex arrays, especially compiled VAs are good. Also look into the nVidia-extensions GL_NV_vertex_array_range, GL_nv_vertex_array_range2 and GL_nv_fence.
Generally, use DLs for static geometry, CVA or VAR for dynamic geometry, and encapsulate changes of multiple states at a time in display lists, and you should be good to go.
Display lists are usually stored in AGP memory and faster than normal vertex arrays, but can''t be changed (unless you recompile them) and hence only viable for static meshes.
For dynamic geometry, vertex arrays, especially compiled VAs are good. Also look into the nVidia-extensions GL_NV_vertex_array_range, GL_nv_vertex_array_range2 and GL_nv_fence.
Generally, use DLs for static geometry, CVA or VAR for dynamic geometry, and encapsulate changes of multiple states at a time in display lists, and you should be good to go.
use compiled vertex arrays. they are a lot more flexible than display lists, and the render as fast in most cases, and when rendering a lot of geometry they render faster if you cull faces. with display lists you can''t alter what is being rendered.
My Homepage
How many Microsoft employees does it take to screw in a light bulb?
None, they just declare drakness as a new standard.
My Homepage
How many Microsoft employees does it take to screw in a light bulb?
None, they just declare drakness as a new standard.
I gotta disagree with the previous post 
Manually culling single faces before sending the data to OpenGL will in most cases slow you down - from my experience the hardware can have the faces transferred and culled a lot faster than the CPU can determine which faces to cull and to transfer.
Manually culling single faces before sending the data to OpenGL will in most cases slow you down - from my experience the hardware can have the faces transferred and culled a lot faster than the CPU can determine which faces to cull and to transfer.
quote:Original post by Dodger
For dynamic geometry, vertex arrays, especially compiled VAs are good. Also look into the nVidia-extensions GL_NV_vertex_array_range, GL_nv_vertex_array_range2 and GL_nv_fence.
I tried this extension on a geforce 2 with some 3000 triangles and it weren''t a fps faster. how many triangles must there be,that i see a difference ?
quote:Original post by Anonymous Poster
I tried this extension on a geforce 2 with some 3000 triangles and it weren''t a fps faster. how many triangles must there be,that i see a difference ?
Try a scene with higher polygon count. Actually you should see a difference (also make sure you have VSync turned off to see the performance increase). VAR allocates the vertex arrays directly in video or AGP memory, so access to these memory blocks should be faster, and also the card either has the data where it needs it (in video mem) or can pull it directly from AGP mem (you save transferring the data from host memory to AGP/video memory).
Make sure you set the parameters for write frequency according to the specification, and make sure you write sequentially to the memory blocks - since AGP memory is uncached non-sequential writes can be very slow.
Besides that, of course, use only the pointer you get when allocating the memory with wglAllocateMemoryNV() for a vertex array and don''t use any intermediate pointers you allocated in host memory (which I think you figured out by yourself since that would kinda defeat the purpose).
Finally, look into using the fence extension - fences provide an easy means of knowing to which point the GPU has processed the vertex array, so you can start filling it with the data for the next frame/scene/object while the card is still pulling data from it, so you can really synchronize the CPU with the GPU.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
