Been working a basic engine out in my head lately and have come down to a few questions on the design. It deals with optimizations on a grand scale and speed from it. I''m trying to look at the polys as a nice big bowl of alphabet soup, each poly needing a texture, material, and possibly alpha sorting. Now typically it is best to have the polys sorted by texture so you have fewer texture switches, and also the same for materials right? And sometimes you have to sort the polys by z depth so that alpha is done correctly. Well my question is, if I need to sort by z depth for alpha, I can''t throw the polys in big texture chunks then. How can you get acceptable speed on a high detail - large poly scene? I''ve been trying to come up with a design that can take this into account and it just isn''t coming to me yet. The one possibly acceptable design is to sort objects by z, then draw the objects based on texture and material sorting (or possibly z depth if it needs alpha). Is this a good method? Also, in a quick test app I''ve written I am getting horrible speed. My object has ~5000 polys. I am drawing it 3 times to the screen using the AndyPike tutorials. They are all rotating on an axis, lit by one light, and drawing a total of ~16,000 polys per frame. Problem is, I''m only getting about 20 fps on a 1GHz puter with a GeForce 4 MX 440. That seems a bit low to me. I''m using D3DXMesh for the X file loading and rendering. Is this common for a D3DXMesh? Or is the code probably just not optimized elsewhere? I''m trying to get an idea so I know where to look when I work on my simple engine. PS - I''m not going to be making a full blown blow-your-mind-landscape-rendering-bsp-tree-rendering-octree-rendering engine. I am going to be working on a simple engine that mostly just throws a poly soup at the screen. But I want to optimize that soup so it draws as fast as possible... Always remember, you''''re unique. Just like everyone else.

im doing something similar atm... and i''ll just throw a few things in your direction for you to think about...

Triangle strips: It is possible (and not that complicated) to reduce an arbitrary model into triangle strips (which are faster to render), instead of processing each vertex/triangle independantly.

You mention transparency. The way i handle transparency is just to draw them all last, as i think you implied. I dont tend to sort by depth, unless i''m drawing transparent objects which then have to be drawn back to front.

if your scene is very detailed the best way to optimise is to send over as few vertices as possible and change state as little as possible.

good luck, i hope i''ve helped!

-jonnii

"If your scene is very detailed the best way to optimise is to send over as few vertices as possible and change state as little as possible. "

I agree with the second part of that but not the first part. On T&L hardware, you want to load a VB with as many verts as you can, then unlock it. AGP transfers data in 64KB chunks, I think. If you are just loading a few verts at a time, you will not get effeciency out of the hardwware.

T&L loves verts. Don''t hand feed it. Drop a HUGE bowl in front of it and let it loose.

Triangle stripping and cache hit optimization are the biggest things you can do to optimize vertex throughput. And fully loaded VBs.

what i mean about sending over as few vertices as possible, isnt sending them over in drips and drabs, but making sure your not sending over vertices that you dont really need, and which can be optimised away with stripping...

-jonnii

As in don''t render things that don''t need to be rendered?

Stripping doesn''t remover verts. It actually adds degenerate faces that the card needs to deal with, but it''s not a big deal. Stripping just reduces the number of indices that are needed, saving card memory, and helps in cache optimization.

You should still do full certex cache optimization as well. It helps a lot.

Thats what I said. It helps vertex cache optimization.

It''s very important to optimize verts so they don''t get transformed twice. Tri strips might still transform a vert twice, it depends on when the vert is used in the strip.

You can optimize lists to be cache optimized as well. Strips are just inherantly cache optimized, somewhat. You can still optimize them better.

On a related tangent. How do you collision detection/wall detection within the poly soup?