Ok, I investigated a bit this myth.. well, everybody says that my models render faster if they are assembled, so that I save entity amount. Okay, here I go: I did a pattern based building with no skin attached (just directX material definition). I ran it under 1024x.. resolution, 55800 polygons are rendered in this shot, overall an assembled model of all tiles would have a total polygoncount of ~220000 polygons. This pattern based building renders with ~73 fps on my machine. Specs: 3 Ghz P4, radeon 9800 pro, latest drivers, A6 comm 6.40.2. Windows XP.



Ok, I merged each 4 rows into a MDL and the last row and the roof tiles into a MDL. So... the same building, but built from 3 entities. The same polygoncount here, but a rendering speed of 30 FPS (!!!)


Ok, all you magicians out there, all the ones which draw here a long bow, WHAT THE HELL IS THIS?

You can download for free my models, they were done just for this stress test in Wings3D, here is the link:

download archive

You have to reassemble it on your own in WED, but that shouldnt be the problem.

Please discuss here this phenomenon.... I want to be sure how I merge my models in my levels to increase performance instead of decreasing it - that would be a nightmare.

Ciao
Christian

That is weird. Oh, and look at your second screenshot. You're getting -16714 kilopolygons per second (negative - weird!). The file you have doesn't open (an "open with" dialog comes up when double-clicking it).

I suspect that the cause to it is actually the fact that the object has the exact same design and the calculations are quicker to do. Unique entities have their vertices different and duplicates have fewer calculations involved. That is an interesting phenomenon. The fastest kps I've ever had is 4000-something (180 vertices and 5000 polygons - it was an experiment), 1200 for otherwise similar things.

Ah, I even didnt saw that kilopolygons per second thing. Weird, the second encounter of negative values in the statistics panel, I'll post that in bug hunt.

I downloaded my file again and I can open the RAR archive as expected and all MDL are working. You should save it, not open it.

Bye, Christian

RAR - that's why. I can't open these files. I did save it to disk and opened it through Windows Explorer (double-clicking it). I thought it was a ZIP archive, of which I can open. I haven't noticed negative values myself yet, just the usual ones such as the position and viewing angles, but that's it. I haven't messed with the engine that much though, mainly just MED.

it isnt wired, because every model is sent into the rendering pipeline. if you have 1000 models this sending mechanism will be used 1000 times. and that is definately taking longer than for one model.

imagine you go to the postoffice and send one big package including 1000 parts to the same adress. the package will be weighted and paid and handled. if you send them one by one, well you know that no other person will be able to send its package that day;)

What are you talking about? The FPS in the first shot with 124 entities is faster than the assembled one in the second shot? Or did I misunderstood your metaphor?

omg, i think it was me misunderstanding you:) nevertheless, it was a nice metaphor

Ello probably gave unvoluntarily the right explanation:

If you send 1000 models into the rendering pipeline, CPU and GPU can run in parallel, the CPU preparing the next rendering steps while the GPU is processing the pipeline.

However one extremely large object will need the CPU to wait for the GPU, thus wasting processing power. This is the unbalanced pipeline case that should also be avoided by level design.

The latter case is only slightly slower, but due to the 60 Hz lock you'll see a huge difference in fps.

However, do not use this result as a level design rule! In a normal level, few large objects always render faster than many small objects. Both methods tested here are equally bad. Try to divide the polygons among 30 objects.

As to the negative bps, I'll download the model and look into that problem.

JCL, very good point, something I never considered before. So sometimes Large batches are not desirable?

I would say it depends on ratio complexity to size. its all about keeping the data pack transfers cpu-> gpu smooth. no differnt that the issues of BUS before. the pipeline/bus speed can;t match the speeds the cpu and gpu works match. So to keep from clogging up the pipeline keep the amount of data to send limited as you can....

or you need to manage what OTHER things your doing along with graphics. 1 reason why allot of 3D sound fx and music conflict with pushing the graphics at the same time, or too much other rendering items/complex textures WITH a shader

you are always finding balances efficiancy <-> quality.