Low poly model performance - help.

I think I''m gonna second the request for an answer to this one. I''m having a very similar problem with my models. I''m runnin'' an AMD Athlon 1GHz, GeForce 3, and 512MB RAM.

Ryan

Yes, you can reach high poly count only if your rendered models contain lot of triangles. Low poly models will kill the performance because of the huge number of rendering and state changing calls. You can load all your low poly models in one vertex buffer (assumed that you use only one texture) and then you can render all your low poly models with only one rendering call.

Maybe it''s the overhead of every model.
Because you have more low-poly models, the overhead is greater and this will result in Performance problems

It ain´t woth it to render low poly models, less then 3-4000 vertices and the overhead with state changes and AGP transfers takes more time then the rendering, try to have as many models in the same vertex buffer as possible and keep the state/texture changes as low as possible.

There are some assumptions being made here... is your problem polygon related or fill related?

If each of your 64 poly models take up the same screen space as the 1362 poly models, then each of the polygons in the 1362 poly model is much smaller. And even though you''re rendering more polygons to the screen, each of those polygons takes much less time to draw.

If on the other hand each of your 1362 polygons was the same size as each of the 64 polygons, then your frame rate would most likely have dropped significantly more, but that''s only a guess.

Most likely it''s a combination of factors, and you can''t just point to polgyons and say "there''s the culprit!" without more thorough tests.

>Why not tell us a few things, like how you''re rendering them, what graphics card, what kind of machine,

Athlon 800, Geforce 1. Using the sample program Optimized Mesh (except I have multiplied the render by 100 (on top of each other)).

>Maybe it''s the overhead of every model.
>Because you have more low-poly models, the overhead is greater and this will result in Performance problems

Yes. Although I only have one texture for the models.

>You can load all your low poly models in one vertex buffer (assumed that you use only one texture) and then you can render all your low poly models with only one rendering call.

Don''t understand. Each model has it''s own world matrix.


Surely there must be a way to render LOADS of models?? I specifically want to populate my world with lots of low poly models, mixed in with a few high poly models.

Sorrow - I will look into it and post back the result.

Oh.. and one other thing....

make sure mip-mapping is turned ON and that you allowed mip map levels to be generated for your texture. I believe mip-mapping is off by default.

This was my number one performance killer when I did similer tests with 12 polygon models vs 2600 polygon models.

OK I will look into Mip Mapping. As to your previous question, I rotated the low poly object to a position where all the polys get backface culled, and this boosted the results to 2500000. A lot more than before, but still half that of the higher poly model (which is actually drawing its polys).

quote:

---

>Maybe it''s the overhead of every model.
>Because you have more low-poly models, the overhead is greater and this will result in Performance problems

Yes. Although I only have one texture for the models.

---

There are sources of overhead other than textures. One example is the vertex cache... its'' going to get flushed once per model, but in the case of the 48 polygon models that''s once per 48 polygons, in the case of the 1362 polygon model that''s once per 1362 polygons. Your second ratio is much better than the first, so you might conceivably get better milage with the vertex cache. To what extent that particular issue effects rendering I can''t say, but it''s just an example of a non texture related performance issue.

Even then... when I was doing tests( a while ago) I seemed to have a constant, but concurrent, "overhead" associated with textures. If I was pushing enough polygons the overhead was hidden, if I was pushing too few the overhead became my performance limitter. Dont'' ask me why this was the case, I have no idea what the driver was doing. (note.. this hit was directly related to the size of the texture and greatly reduced with mip mapping.)

Nothing''s ever simple.

quote:

---

>You can load all your low poly models in one vertex buffer (assumed that you use only one texture) and then you can render all your low poly models with only one rendering call.

Don''t understand. Each model has it''s own world matrix.

---

Perform the world transform in software.

Could we get a specific description of how to place all the subsets of an .x file mesh into one vertex buffer? And how does one force the world transformation to be performed in software? Thanks!

Ryan

quote:

---

Could we get a specific description of how to place all the subsets of an .x file mesh into one vertex buffer?

---

No clue... I don''t use .x files.

quote:

---

And how does one force the world transformation to be performed in software? Thanks!

---

It''s not a flag you set... if I wanted to take a bunch of my own low poly objects, do the world transformation myself and then shove them into a single big vertex buffer I''d do just that.

I''d save the models in an array (not a vertex buffer... though I guess a system memory vertex buffer coudl be used if you really wanted to.), and then do the world transform on each vertex in software (i.e. I''d program the process in myself) and pass the results along as I fill up a dynamic vertex buffer and index buffer. If I was using 100, 64 polygon objects, I''d end up with a single vertex buffer and index buffer describing all 6400 polygons in world space co-ordinates.

You can turn on or off hardware transform/lighting, but that''s the entire transformation pipe and has nothing to do with what I was describing.

I''m not advocating the approach... just describing it. I don''t think it would be a big enough performance gain in most cases to justify the spent cpu time (but haven''t done any testing so that''s an assumption.)


There IS a process vertices method in D8 which might be set up to do the actual transform for you... but I''ve never tried to use it. It woudln''t surprise me if it''s efficient on system vertex buffers, but I''ve never tried it.

How do you use vertex buffers with something you''ve modeled in 3ds MAX or TrueSpace? Or can''t you? If you can''t, why would you use manually programmed vertex buffers to create geometry? How in the world would you create complex objects?

Sorrow, Do you think that method would speed it up much ? I do something similar (on Simon O''s advice) with my particles to allow for batch rendering.

The other thing I could do is make these models part of the world mesh (as they are all just non animating instances), but this seems such a waste, and takes away the possibility of effects that having them as models would allow.

here is a small example:

I have created a tree model with 3DS MAX and exported an X file. Then I wanted to render 1000 trees on a terrain surface. Every tree has a position (and trees don''t often change it :-), so I called 1000 times the rendering allways setting the world matrix before rendering the actual tree. The result: that is damned slow!!!!!
So I created a vertex buffer (and an index buffer), I took the tree, transformed it''s vertices 1000 times using always the right transform matrix and copied the result in the vertex buffer. So I have a vertex buffer with 1000 trees placed already on the right position. The result: that is damned fast!!! Amazing!! It is then absolutely fill rate limited!!!

That''s a bit rubbish though isn''t it ? Having to do that.

Here''s an extension to your scenario, you boss says to you "can you animate those tree in the breeze?". You say "No". Shoving everything in a big VB 1) Wastes memory and 2) Costs flexibilty (you can no longer animate the trees, or blow them up, etc).

I can not see why there is such a big over head in starting a render.

quote:

---

Sorrow, Do you think that method would speed it up much ? I do something similar (on Simon O''s advice) with my particles to allow for batch rendering.

---

I can''t really say, I''ve never tried it. I just know that in theory it''s one way to go about it. If you think it might help you can always do a quick hack on your engine to try it out. It certainly shouldn''t slow you down (or shouldn''t if you use the dynamic buffer properly.), but it eats up some cpu time (where as just rendering the static buffers only takes the gpu''s time).

quote:

---

The result: that is damned slow!!!!!

---

Since you''ve done the test, can you clarify that with a number?

quote:

---

The result: that is damned fast!!!

---

I''m guessing not quite as damned fast as it is damned slow... as you gave the damned fast TWO less exclamation marks A number here would also be nice.

The other question is, how many polys are in each of your trees?

Asside from that, 1000 trees is ALLOT of trees... so you''re in one of two situations here. You''re either so far back from the trees to get them all on screen that you''ld never notice them individually swaying (you''re looking at the forest.) or you''re in close enough to observe individual trees but now all but maybe 50 or 100 of the trees are obscured by other trees (you can''t see the forest for the tree ).

That said I can only assume you''re talking about tree bill boards or something, because otherwise you''ld run smack into the buffer size limit. You can''t have more than about 64k vertices in a single buffer on most cards (including geforce2 cards). If you had more than 64 vertices on each of these 1000 trees you''ve already blown past your buffer limit. (64 isn''t much at all.. seeing as how a simple cube has 24)

So either these were ultra low poly trees (which you wouldn''t want to get close enough to to see swaying), or I don''t know. The software test rasterizer would let you use bigger vertex buffers probably...

yes! those were ultra low poly trees. and of course when I have to animate something I will not put the data in a static VB. all that was only a possible example how to speed up low poly rendering. the topic asked about low poly models. I will check the numbers too, but as I said in the second case the rendering is fill rate limited in my Geforce2 MX card.

Here are the numbers:

system:
Celeron 300A running on 375MHz
128MB RAM
Geforce2 MX videocard with 32MB

Running program drawing only the menu: 155 FPS
Rendering 1000 trees merged all in 1 VB: 129 FPS
Rendering 1000 trees separated: 14 FPS

Yes, rendering the trees with only one call is about 50 times
faster!!!
You can ignore this possibility of optimization but I don''t think it is clever...