High-poly model XNA 10 FPS !

Started by
19 comments, last by xexuxjy 11 years, 6 months ago

When you draw something CPU validates whether you have set correct Vertex Buffer, Index Buffer, Shaders, and all other states.

When you don't draw anything you're basically spamming GPU with command "Show this on the monitor". It probably hits memory bandwidth limit because it attempts to copy your frame everytime.


so the only solution is to use less poly model and using multithreading to eliminate the CPU bottleneck?
Advertisement
Well the first thing to do is cap the number of frames you show per second, because nobody gets any extra benefit from 2500 fps as opposed to 100 fps, and if you give your (or your player's) graphics card some breathing space it will run cooler and probably live longer.

The next thing to do is reduce the polygon count. Ideally I wouldn't go for more than 1 million vertices per frame, even with the most efficient state changing systems. 150k poly for a tree (!) is completely ridiculous, and unless its a game about tree surgery, nobody's gonna notice the difference between 150k polys and 8k polys.

Finally. The sample XNA draw model code looked terrible when I last saw it a few years ago. Whenever you change the current pixel shader (by changing the effect), the gpu has to finish drawing all models with the current shader before it can change, which causes a delay. The better approach is to draw everything that uses the same shader in one go, then switch to the next shader and repeat, changing the constants/parameters as you go. If you can then reduce the number of changes of texture, it will run even faster.

Lastly, group as many things as possible into one draw call. Nvidia recommends about 300 draw calls per frame in total (this might be a bit out of date though).

Well the first thing to do is cap the number of frames you show per second, because nobody gets any extra benefit from 2500 fps as opposed to 100 fps, and if you give your (or your player's) graphics card some breathing space it will run cooler and probably live longer.


Yah I know, I'm just doing that to show how much the model decreases my FPS.


The next thing to do is reduce the polygon count. Ideally I wouldn't go for more than 1 million vertices per frame, even with the most efficient state changing systems. 150k poly for a tree (!) is completely ridiculous, and unless its a game about tree surgery, nobody's gonna notice the difference between 150k polys and 8k polys.


Ok I was wrong about one thing. The tree model has 80K polygons and 150K vertices Now your saying that I shouldn't go above one million vertices per frame. well I only have 150K vertices. so I must be doing something wrong?


Finally. The sample XNA draw model code looked terrible when I last saw it a few years ago. Whenever you change the current pixel shader (by changing the effect), the gpu has to finish drawing all models with the current shader before it can change, which causes a delay. The better approach is to draw everything that uses the same shader in one go, then switch to the next shader and repeat, changing the constants/parameters as you go. If you can then reduce the number of changes of texture, it will run even faster.

Lastly, group as many things as possible into one draw call. Nvidia recommends about 300 draw calls per frame in total (this might be a bit out of date though).


How can I do that? Can you direct me to some website that show a better / faster way to render the models?

I'm sorry I just got into 3D like a week ago smile.png

and I got 5901.


If you mean that the number of meshes in your model is 5901, that would definitely be your problem. That would mean 5901 draw calls every time you draw the tree.


Lastly, group as many things as possible into one draw call. Nvidia recommends about 300 draw calls per frame in total (this might be a bit out of date though).

[quote name='FantasyVII' timestamp='1350465788' post='4991064']
and I got 5901.


If you mean that the number of meshes in your model is 5901, that would definitely be your problem. That would mean 5901 draw calls every time you draw the tree.


Lastly, group as many things as possible into one draw call. Nvidia recommends about 300 draw calls per frame in total (this might be a bit out of date though).

[/quote]

Ok but how do i do that? how do I set only 300 caller per frame?
Have you count the number of effects? Each ModelMesh in XNA is futher divided into ModelMeshPart, so it may take more then 5901 batches.

Ok but how do i do that? how do I set only 300 caller per frame?


I'm not familiar with SketchUp, but it should have a way to combine the separate pieces.

Ok I was wrong about one thing. The tree model has 80K polygons and 150K vertices Now your saying that I shouldn't go above one million vertices per frame. well I only have 150K vertices. so I must be doing something wrong?


Well, 80k polygons is 240k vertices that need processing. Many of these are vertices that are shared between triangles of course - if those triangles are processed close to each other (in time), then the GPU can re-use the results. So in reality, you'll be pushing somewhere between 150K and 240K. Hopefully closer to the former, if the code that generated the mesh ordered the triangles efficiently.

80k polygons is a huge amount for a tree. If you plan to be rendering more than a handful, you'll definitely want to make this a lot lower.

But anyway, like I think you've discovered, it's most likely the number of batches you're rendering that's the problem. 5901 batches! That's really only necessary if you're using 5901 different materials. Presumably your trees uses a maximum of two (one for the leaves, one for the trunk)... hopefully the program you used to generate it can combine the meshes to reflect that.

[quote name='FantasyVII' timestamp='1350473920' post='4991089']
Ok I was wrong about one thing. The tree model has 80K polygons and 150K vertices Now your saying that I shouldn't go above one million vertices per frame. well I only have 150K vertices. so I must be doing something wrong?

Well, 80k polygons is 240k vertices that need processing. Many of these are vertices that are shared between triangles of course - if those triangles are processed close to each other (in time), then the GPU can re-use the results. So in reality, you'll be pushing somewhere between 150K and 240K. Hopefully closer to the former, if the code that generated the mesh ordered the triangles efficiently.
80k polygons is a huge amount for a tree. If you plan to be rendering more than a handful, you'll definitely want to make this a lot lower.
But anyway, like I think you've discovered, it's most likely the number of batches you're rendering that's the problem. 5901 batches! That's really only necessary if you're using 5901 different materials. Presumably your trees uses a maximum of two (one for the leaves, one for the trunk)... hopefully the program you used to generate it can combine the meshes to reflect that.
[/quote]

hmmm...

Ok then thank you guys so much. that really helped.

I'm now looking at Hardware instancing. because I'm trying to draw around 10,000 cubes (24 vertices each cube) at the same time. and Hardware instancing really really helps.

before using Hardware instancing my FPS was around 15 FPS and I was able to render 10,000 cubes. After using Hardware instancing I can now render 100, 000 at 45 FPS. The only problem is that Hardware instancing is a bit complicated for me.

anyways thank you all smile.png
Glad to see my advice was of use.

Now if you're making a game with a Minecraft style world, instead of drawing every single block as a cube you can split the world into chunks - Minecraft uses 16x128x16 blocks per chunk. Then draw the chunks near the player using the instancing method - this allows you to create and destroy blocks near the player cheaply - and combine all blocks in further away chunks into smaller meshes.

These articles are helpful reading

http://0fps.wordpress.com/2012/06/30/meshing-in-a-minecraft-game/
http://0fps.wordpress.com/2012/07/07/meshing-minecraft-part-2/

This topic is closed to new replies.

Advertisement