How many (low poly) models can XNA handle?

I know the following is a vague question, but I am facing performance issues that I did not expect in XNA.

I have a low poly model (it has 18 faces and 14 vertices), which I try to draw on the screen (large!) A number of times. I get over 60 FPS (in a decent car) until I draw this model 5000+ times. Am I asking too much? I would very much like to double or triple this number (10-15 thousand), At least.

My code for actually drawing models is below. I tried to eliminate as many calculations from the pull cycle as possible as quickly as possible, can I still compress from it, or is it better to work together?

Note: tile.Offset is evaluated once during initialization, and not in each cycle.

foreach (var tile in Tiles) { var myModel = tile.Model; Matrix[] transforms = new Matrix[myModel.Bones.Count]; myModel.CopyAbsoluteBoneTransformsTo(transforms); foreach (ModelMesh mesh in myModel.Meshes) { foreach (BasicEffect effect in mesh.Effects) { // effect.EnableDefaultLighting(); effect.World = transforms[mesh.ParentBone.Index] * Matrix.CreateTranslation(tile.Offset); effect.View = CameraManager.ViewMatrix; effect.Projection = CameraManager.ProjectionMatrix; } mesh.Draw(); } } 
+5
source share
2 answers

You will explicitly hit the batch limit . See this presentation and this answer and this answer . Simply put: there is a limit to the number of call requests that you can send to the GPU every second.

A batch limit is a CPU based limitation, so you'll probably see that your processor gets bound when you get to your 5000+ models. Even worse, when your game performs other calculations, it will reduce the processor time available to send these parties.

(And it’s important to note that, on the contrary, you almost certainly do not fall within the GPU. No need to worry about the complexity of the grid.)

There are several ways to reduce the number of parties. Frustum is rejected. Probably the best in your case is Geometry Instancing , this allows you to draw several models in one batch. Here is an example of an XNA that does this.

Better yet, if it's static geometry, can you just bake it all into one or more large grids?

+14
source

As with any performance issue, there are limitations in which a particular approach works. You need to measure and see where the problems are. The best option is to use a profiler, but even basic measurements, such as viewing CPU usage, can show which bottles you have.

As a first investment step, I would recommend deleting all the calculations (e.g. matrix multiplication) and see that you are getting improvements - this will mean that the processor is still working more than the GPU.

Make sure that you are not taking measurements in the debug assembly - this can make the application much slower if it is connected to the CPU.

Side note: The GPU works best when you send large operations relatively rarely. Your code is more or less the opposite - it sends a huge number of very small drawing requests. You should be able to download your primitives and get better performance. There are examples of how to display a large number of simple objects (including in the DirectX SDK), the search for “crowd rendering gpu” can give you a starting point.

+3
source

Source: https://habr.com/ru/post/889654/


All Articles