Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

onnel

Backface culling with Dx8

This topic is 6094 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Should I do it myself or use the default d3d backface culling? Is there a speed problem with using the default culling? The reason I thought there might be a performance hit with the default method is that if it is being done on the hardware, I still have to transmit all of these triangles which are actually backfacing. Am I worrying about nothing? Thanks! Onnel Edited by - onnel on September 20, 2001 5:45:31 AM

Share this post


Link to post
Share on other sites
Advertisement
If you can backface cull manually in less time than it takes to send the vertices to the hardware, then do it. Otherwise let the hardware do it.

If your manual backface culling is doing the cull per polygon, then it''s very unlikely it''ll be faster.

Related to that is the fact that if you send less than about 100 polygons per draw call you get bad performance - doing your own backface culling would usually end up with lots of little draw calls where you are skipping backfacing vertices.

Only do it if your cull can chop off 100 or so polygons with a really quick test. An example is quantizing normals into 16 different directions and then pre-ordering all polygons (& vertices) into 16 separate groups. To cull you do a test on the quantized direction and submit or reject the whole group which roughly faces that direction (so you cull a group with one test).



--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
great feedback. I think I''ll go with the default culling, but there certainly is the possibilty for some later optimization based on what you told me...thanks!

As an added question: I knew about 100 polys being the beginning of the "sweet spot" and less than that being inefficient. I assume there''s nothing that can be done in cases where you simply have less than 100 polys using the same texture. For example, if I have a few walls, maybe 20 polys, and they don''t share their texture with anything else, there''s no real way to optimize that, is there?

Thanks again for the excellent feedback!

Onnel

Share this post


Link to post
Share on other sites
For T&L cards the minimum is around 100, for older non-T&L cards (where D3D is doing the T&L in software) it''s around 20. Those are really minimums - the sweet spot is probably [*] upwards of 2000.

Theres not really that much you can do about those small batch cases. A few ideas though:

1. Use bigger textures where possible (many cards do 1024x1024, some do higher - one idea is to look at the caps at load time and merge lots of smaller maps, particularly those used in inefficient batches into a single bigger map. Tradeoffs - filtering and mipmapping issues since you''re tying different maps together.

2. If you have lots of small static objects each with their own transform, but the same renderstates, transform them all into world space and draw them all in one go with the world matrix set to identity. [merging textures helps find more to join].

3. Experiment with passing small batches in dynamic buffers - the driver may [*] do clever stuff like delay small transfers until there is enough data.


[*] It''s not an exact science - different drivers, CPUs, graphics hardware, motherboards etc all effect it.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!