So 50,000 entities with one polygon each, will clog the pipeline as would the
same model consolodated into one entity with 50,000 polygons. But if we
consolodate the models into 10 entities with 5000 polygons each, we may render
faster because our "chunk size" is more ideal?

Is it possible to know the best ratio of polygons per entity if the total of
each are known? A "Most Polygons Per Entity" rule? Or is the ideal "chunk size"
machine and card dependant to such a degree that it it cannot be quantified?

Surely when you need to render 100,000 polys, 10 polygons per entity is too low
and 100,000 too high, so there must be a range that fits best with modern
graphics capabilities somewaht across the board.

In HeelX's experiment, he contrasts different ratios of visible polygons per
visible entities.

55800/124 = 450 visible polygons per entity = 73fps
55800/3 = 18600 visible polygons per entity = 30fps

It would be interesting to see a wider range of results at different ratios.
Would 248 visible entities with 225 visible polys each, render slower, faster
or the same? Where does the curve peak?

Sounds like a job for Uli.

Given that everyone has different processors and video cards, this curve peak could vary some. A high end video card (like the Radeon X1600) with a low end processor (like 1.2 GHz) could have a much different result over a low end video card (like Radeon 7000) and a high end processor (like 3.8 GHz). It also seems to be dependent on the OS as well. When I switched to XP from 98, my game was running 50% faster and ran experiments with known files and screenshots to compare the results to verify this. I wonder what effect a closed mesh has over an open mesh in terms of the frame rate to see if that has anything to do with it. Oh well, now I just need to figure out how to go about running the experiment in greater depth....

Uli, you are right, that is the MOST painful job (and underestimated) in the games industry: making a game running with full speed and full quality on every customers system. Since there are infinite settings (plus, an user could have messed up his/her PC as well with software and drivers which slow dow everything else, too), it is a quite impossible thing. So.. maybe you should focus on a regular PC.. BUT let us dont talk again what means regular in a few years.. I see a debate again about graphics in general and shaders... BLABLABLA. So let me post two pics here:

Instead of merging the tower in 3 big parts I merged the corner models into a whole model, the side is now one model and the roof is also one model. So, 4 corner models sharing the same geometry, 4 sides sharing the same model geometry and one single roof model.. makes 9 models. Result: FPS doubled:


This is about 8700 tris per ent (approx). Well.. quiet too much, but it works better now.

Next try:

I switched back to the very first version where I used for the sides single tiles. Since one row consists of two corner tiles on the borders there are only 2 in the middle of a row. I merged 2 single tiles and replaced them instantly.

Result: FPS increased, very high fill rate (see shot), FPS: ~100 at ca. 1000 tris per entity:


To get the number of the visible triangles, I used num_vistriangles, but the value was different between the two shots (20000 more tris during the second test).

Well.. an indicator for rendering speed is the kps thing under the FPS stat, if its very high, the fill rate is optimal and the result is a high FPS.

Ciao
Christian

My base concept is a 3-stage logarithm of 10. That is, the polygon count increases tenfold every three steps higher. For simplicity, I'm using simpler numbers. The polygon count always will start with 1, 2, or 5 and end in from 1 to 5 zeros (100,000 is the highest, 200,000, requiring over 100,000 vertices, will not work with MED as the mesh doesn't get saved properly (DirectX limitation)). Now to take out my experimental level (a level that contains just one small block (default texture and invisible), a position, and all test subjects, duplicates in particular.

Experiments are a great way to optimize something. This way, you can find the peak performance for your game and learn better techniques to optimizing. You always need a base to branch off from (the control as it's called). From there, you provide variations.

Dont forget to use "real life models" instead of grids or so... I expect grids for instance to be rendered faster because of their nature of repeating patterns.

I don't think it actually makes any difference whether or not I use "real life models". What's being done is that each vertex position is calculated then the polygons are drawn, and finally the textures are applied along with the entity's material and any shaders it has. I did use grids though.... They're fast and easy to create. Here are my experiment results, including a chart and a graph (logarithmic graph that is).



Code:

---

+---------------------------+
|        object count       |
+-+-----+----+----+----+----+
| |     |  64| 128| 256| 512|
+-+-----+----+----+----+----+
|p|   10|  78|  91| 100| 102|
+-+-----+----+----+----+----+
|o|   20| 154| 175| 198| 207|
+-+-----+----+----+----+----+
|l|   50| 380| 438| 476| 501|
+-+-----+----+----+----+----+
|y|  100| 720| 830| 910| 950|
+-+-----+----+----+----+----+
| |  200|1330|1510|1660|1750|
+-+-----+----+----+----+----+
|c|  500|2820|3180|3340|3510|
+-+-----+----+----+----+----+
|o| 1000|4310|4930|5050|5320|
+-+-----+----+----+----+----+
|u| 2000|6050|6690|6530|7030|
+-+-----+----+----+----+----+
|n| 5000|6610|6600|6980|6960|
+-+-----+----+----+----+----+
|t|10000|3640|3630| xx | xx |
+-+-----+----+----+----+----+
| |20000|1930| xx | xx | xx |
+-+-----+----+----+----+----+

---

The numbers in the center are the kps values (kilopolygons per second, thus 7030 would mean 7,030,000 polygons per second (a record for me)). I've turned my numbers into a graph. The ones with xx were way too slow (like 3 fps). From looking at the graph, 2000 polygon models have the best impact.

Download my samples here. This way, you can benchmark your development, at least for your system.

These tests were run using 6.40.2, 1024x768 resolution in windowed mode, on XP Pro. My system has Radeon 9600 XT for the video card, a 3 GHz Pentium 4 processor, with 512 MB RAM. I closed Firefox to free 115 MB in memory to prevent the case of excessive swapping (which is why I wasn't here for several hours - I need the memory (I'll be getting more come March)).

you would get mroe speed out of that building by eliminating some of the physical details ( thus reducing polys and verts), to be replaced by skin texure details

models in a game engine its structure is about the silhouette

how I would approach building this would probably be first trial like this:

the main structure of 4 walls and then the ledges in one structure ( basicly a block/cube surrounded by smaller blocks/cubes to make the ledge)


the "horn" like protrusions I would build one example that rings the building level as well as the pipe like protrusions on the roof. also if you real need the physical details of teh windows build that as a single model for a floor level.

all these detail model extras then can be build with LOD in mind

everything else should be done in the texture.

Grimber, I am used to do this, I had a different approach in my mind. I merged the whole building and it was too high poly that the engine produced an error during MDL loading. Then I splitted it and expected a higher framerate as when I use single tiles. It wasnt so, so I posted here. I'm in preproduction, so I dont do any modeling here, I'm just testing.

Very interesting Ulillillia, Thanks for sharing your experiment results.
I take it that all the polygons where visible? If so, It would seem that
when consolodating entitys such as trees into single model entity, the
consolodated model could have a higher than 2000 polygon count, just so
only ~2000 are visible from any viewpoint at one time.
Does that sound right?