geforce 3 culling
Author
HiHo !
I just read an article about the geforce3s culling cabablities ... is it true that the card does all the culling for you and you don't have to write ANY culling routine (View-Frustum,Occlusion) ?
If so : there has to be a speed improvement from the "best" culling routine to the none-culling-at-all-drawing because the cpu doesn't have to compute what is visible !?
And what about the transparency : do you have to draw the transparent objects/polys ordered for correct results ?
thx
-m0rs
Edited by - m0rs on April 23, 2001 2:13:34 PM
I''m not sure if this is the answer you want, but here goes :
OpenGL already does culling for everything you send to it.
(I''m not sure about DirectX, but it probably does too)
I''m not sure how efficient the GeForce3 is at this, but if you send 10,000 triangles to the video card without culling, and only 3 of them turn out to be visible, thats still 9,997 triangles that are not only processed by the video card, but also the OpenGL/DirectX drivers before they are discarded.
To answer your question, it will be a trade-off between cpu processing and GPU processing. It will likely still be more efficient to use a good culling algorithm, because (for example) a BSP tree can eliminate about half of all triangles with a simple greater than/less than test (assuming the tree is well balanced).
The GeForce3 gpu will not likely have built in support for proprietary culling structures (bsp trees,oct/quadrees, etc.)
Last, and most important, not everyone will have a GeForce3, and if forced to buy one for a particular game, that game will likely fail.
The best thing to do would be actual benchmarking (assuming you have a GeForce3 handy )
Good luck
Feel free to email me.
OpenGL already does culling for everything you send to it.
(I''m not sure about DirectX, but it probably does too)
I''m not sure how efficient the GeForce3 is at this, but if you send 10,000 triangles to the video card without culling, and only 3 of them turn out to be visible, thats still 9,997 triangles that are not only processed by the video card, but also the OpenGL/DirectX drivers before they are discarded.
To answer your question, it will be a trade-off between cpu processing and GPU processing. It will likely still be more efficient to use a good culling algorithm, because (for example) a BSP tree can eliminate about half of all triangles with a simple greater than/less than test (assuming the tree is well balanced).
The GeForce3 gpu will not likely have built in support for proprietary culling structures (bsp trees,oct/quadrees, etc.)
Last, and most important, not everyone will have a GeForce3, and if forced to buy one for a particular game, that game will likely fail.
The best thing to do would be actual benchmarking (assuming you have a GeForce3 handy )
Good luck
Feel free to email me.
quote:
If so : there has to be a speed improvement from the "best" culling routine to the none-culling-at-all-drawing
Nah, not really. As the cull is done in hardware if the chip is designed well it should be pretty much pipelined ie you calculate one triangles verticies, pass it over to the hardware that does the clipping and can start calculating the next triangle without waiting for the result, (or more likely for the pixels to drawn, which will problably take much longer).
quote:
And what about the transparency : do you have to draw the transparent objects/polys ordered for correct results ?
Yep, you always have to do that with any rendering system that doesn''t reorder your triangles into furthest-nearest z-order.
And seeing as you have to draw the standard triangles in nearest-furthest z-order to get the advantage of the early z-cull this is slightly annoying.
cheers dan
Game production:
Good, quick, cheap: Choose two.
quote:Original post by Danack
If so : there has to be a speed improvement from the "best" culling routine to the none-culling-at-all-drawing
Nah, not really. As the cull is done in hardware if the chip is designed well it should be pretty much pipelined ie you calculate one triangles verticies, pass it over to the hardware that does the clipping and can start calculating the next triangle without waiting for the result, (or more likely for the pixels to drawn, which will problably take much longer).quote:
And what about the transparency : do you have to draw the transparent objects/polys ordered for correct results ?
Yep, you always have to do that with any rendering system that doesn''t reorder your triangles into furthest-nearest z-order.
And seeing as you have to draw the standard triangles in nearest-furthest z-order to get the advantage of the early z-cull this is slightly annoying.
cheers dan
Game production:
Good, quick, cheap: Choose two.
Almost…Hardware is gonna be slower if it''s doing the same thing the cpu is and running at 1/5 the clock rate. Getting rid of polys in software is pretty much always going to be better.
Secondly, you always have to draw alpha back to front with any PROCEDURAL rendering system.
I still say cull them in software as you can do it more efficiently for your own circumstances (i.e. would BSP, Portals, or something else be best for this game?), and you''ll save bandwidth on the AGP (or in the worst case: PCI) port.
"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said
http://druidgames.cjb.net/
"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said
http://druidgames.cjb.net/
Author
well thx for the answers ... this stupid article had confused me a bit!
I thought that this couldn''t be the best way to send millions
of triangles to the card which THEN culls nearly all of ''em :D
thx again ... well ... where was this superfast culling algo *search* =)
I thought that this couldn''t be the best way to send millions
of triangles to the card which THEN culls nearly all of ''em :Dthx again ... well ... where was this superfast culling algo *search* =)
You absolutely must cull them before you send them to the card, for optimal performance. One of the biggest limiting factors right now in 3D realtime graphics is the amount of data we can send to the graphics card quickly. If you try and cram down 1000000 verticies, plus normals, and textures, you''re going to get a fairly low fps. You just can''t send the data fast enough across the bus. OpenGL and DirectX will cull for you, but because that happens after the data has crossed the bus, its not terribly efficient. Always try to reduce the amount of data you send to your card. As for "superfast" algorithms, there''s no one end all be all solution. Different problems require different approaches. All I can suggest is research into the matter, unfortunately.
I suggest looking at
http://www.geocities.com/SiliconValley/Park/5625/opengl/
for more information on both culling algorithms and your blending question, as it goes into more detail that I''d feel comfortable doing here
Hope that helps.
DN
I suggest looking at
http://www.geocities.com/SiliconValley/Park/5625/opengl/
for more information on both culling algorithms and your blending question, as it goes into more detail that I''d feel comfortable doing here
Hope that helps.
DN
Author
quote: One of the biggest limiting factors right now in 3D realtime graphics is the amount of data we can send to the graphics card quickly.
yupp ... thats what i was talking about
thx for the url (hmmm ... one site i didn''t know ... whowooo)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
