Models vs. Performance

[kddekadenz]

I think a lot of you already know this problem:

Models decrease performance a lot:


The Sauerbraten Engine, PAS is based on, had already this problem.
I think it is because the viewing distance is too high. Check it yourself: look at the models and check your FPS and then look away and check it again.
The same problem happens to the AI: critters do see you from great distance.

So the way to fix this is a static variable defining the maximal view distance

[chocolatepie33]

So the way to fix this is a static variable defining the maximal view distance

So you're suggesting the variable defines the maximum viewing distance and changes based on average fps, or actual distance?

Also, esequil14 had something about this long ago (models vs geometry), you may wish to look at that. Tree models in general are usually the culprits of low fps, especially when clustered together like shown, which shouldn't really ever happen, unless you're trying for an forest map.

[Hirato]

If you had 90k worth of geometry polygons, I imagine your FPS would also be about 2/3rds of its current self.
Maybe it's time to upgrade from Intel hardware.

:cue emoticon which stares into the depths of your soul:

[kddekadenz]

Yes, I have to get a new computer
Nevertheless models and entities do slow down the game a lot. I think Tesseract will eat some performance, too.

[chocolatepie33]

I think Tesseract will eat some performance, too.

Why is everyone talking about Tesseract all of a sudden? Was there some event I missed out on?

[Runescapedj]

Games nowadays have the same model with different amounts of polygons and detail, max when you are really close, and if you go further away the model would keep going to a less detailed model to eventually change in a 2d sprite at extremely long range. Is something like this possible in PAS? It would increase the framerate a lot

[chocolatepie33]

@Rune: that's a great idea, I was playing a pretty old (Playstation era) game the other night, and that's what happened, but with geometry texture instead of mapmodels. When you were close enough, the texture was fully loaded and clear, but from farther away, you only saw a basic color (e.g. tan, grey, purple), and even farther away you wouldn't have seen the geometry at all.

As for the possibility of it being possible (what did I just say? ), it would definitely be a source thing, but maybe you could measure current fps as a variable and that variable would be the input which controls viewing distance of a model or texture quality (see example below). However, you would need to somehow label which direction and what distance to modify, and the entire idea of it would be ruined, as this would be a horrible loop: when the viewing distance decreases, fps goes up, leading to a higher viewdistance and lower fps, starting the cycle again. Maybe you could "test" for fps at certain time intervals and only apply it then, or maybe you just lock the viewing distance into a certain state until it's tested again.

Example code:

Code: Select all

int "frames" = [whatever determines framerate]  //creates integer variable fps and assigns the value of it to the code which outputs fps (in the bottom-right corner)
int "viewdraw" //creates integer variable viewdraw, which stands for something like viewing distance to draw to
"viewdraw" = [
case (fps >= 200) [viewdraw = 100%] //
case (200 > fps > 100) [viewdraw = 66%]
case (100 => fps > 60) [viewdraw = 40%]
case (60 >= fps) [viewdraw = 20% or less]
]

This is really bad pseudocode, I know some C++ but I've been working with another language for the past few months so it's a mix. Anyways, this says that you have fps as a variable that the engine determines. From there, we could use ranges of fps (seeing as fps varies a lot during a game and rarely stays the exact same for any period of time) to determine what the resultant viewing distance should be until it's tested again.

[Hirato]

so, you guys want LoD. Cube 2 doesn't support it and I doubt it will so we'd have to do that ourselves, and frankly it's not something I particularly care about.


@chocolatepie
If you just want the draw distance to cut off at a point, you can sort of already do that... well, used to. fog is now a world variable, go figure.

Code: Select all

fog (+f (*f $fog .95) (*f (* (getfps) 75) .05))

[Captain_Ahab]

I was wondering...

How much is the lag due to the number of tri's and how much is due to the number of models that the engine has to keep track of.
In other words, which slows the frame-rate down more; one 50,000 tri mapmodel, or 50 1,000 tri mapmodels?

[Hirato]

Rendering wise, assuming the 50 models are all the exact same model, it should be more or less as fast as the one 50k tris model.
the 50 * 1000 would be slower due to various other changes.

Not to mention, having 50 models present would infer a bigger hit on overall performance too as you have 49 additional objects to keep track of for physics.