the fastest cube

Started by
1 comment, last by Sir Valeq 20 years, 11 months ago
Which is the fastest method of drawing a cube? Non-indexed lists? Strips? Indexed lists/strips? Which one is the most suitable for nice texturing and lighting? And the last one: which method is the most proffessional one? Which one do you use? (Which one should I use)
--------------"We cannot all be masters." - William Shakespeare
Advertisement
Admittedly, I haven''t pulled out enough commercial games (Read:none) to speak which is ''best''.

However I know enough about Direct3D to give a few rules of thumb.
Rule #1: Aiming for indexed triangle lists or indexed strips is ''a good thing'', because you send less data to the card (reused vertexes) and the card will find those reused vertexes in its cache while rendering the cube. (An NVidia article I read mentioned there being an ultrafast 10-20 vertex cache in the card''s hardware)
Rule #2: If your cube is not tesselated to more precision than 6 squares = 12 triangles, no matter which technique you use, you won''t notice much of a speed difference.
Rule #3: Texture mayhem. If you use the same texture on all 6 faces, you''re okay. If not you need to rethink the whole thing.

Let''s assume your cube is a crate, with ''sides'' with one texture, and a ''top'' with another, and you have 100 such crates in your scene.

What is faster between these two methods?
1-Rendering all faces with the ''sides'' texture, then roll a ''setTexture'' call to change texture, then render all faces with the ''top'' texture? (Cost: two settexture calls total, two SetWorldMatrix and two DrawPrimitive calls PER CUBE)
2-Rendering all cubes, changing the World Matrix once per cube and doing the two drawprimitives with different textures? (Cost: One SetWorldMatrix call per cuve, two DrawPrimitive and two SetTexture per cube)

If you can make yourself a RenderManager that can shift between those two methods, Kudos! You''d have a small engine that you can profile for various render methods. And you would no longer be limited to the ''one object = one render call'' paradigm, which can limit your possibilities.

I''m pretty sure #2 will be faster, however it is possible to manage putting a bunch of cube-vertexes ALREADY WORLD TRANSFORMED for all your scene''s cubes in a large buffer, then a single DrawPrimitive call will draw the sides of all cubes in your scene. Tricky to manage (Because many game objects have to be accessed and combined, plus removing one cube would make updating the buffer rather costly), but damn fast... (Come to think of it, adding/removing a cube from the scene is typically a ''rare'' event and rendering is a ''very frequent'' event. So even when you need to add/remove cubes it''s a good method... As long as cubes don''t fly around independently.)

Pfew, I hope this gets your brain working. I sure had fun thinking this up.

=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.
=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.
Well, I don''t think you can always assume that index buffers are faster. On my terrain, switching to index buffers increased my FPS significantly because there were lots of shared vertices. This weekend, however, I was working on a skydome which is essentially about 125 squares (250 triangles) arranged in the shape of a semi-sphere. I originally coded it using vertex buffers but after seeing the improvement in the terrain, decided to implement index buffers there, too. Sadly, my FPS actually decreased a tad (1-2 FPS).

bpopp (bpopp.net)

This topic is closed to new replies.

Advertisement