Models vs. Performance

Having issues not related to a specific Sandbox game mode? Get help here!
Please also read the rules for support when posting support requests.
Failure to comply with the forum rules may result in your topic being locked without resolution.
User avatar
kddekadenz
Member
Member
Posts: 423
Joined: July 17th, 2011, 11:02 am
Name: kdd
Contact:

Models vs. Performance

Postby kddekadenz » November 2nd, 2012, 9:52 am

I think a lot of you already know this problem:

Models decrease performance a lot:

Image
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 ;)
Kelgar is an advanced RPG beeing developed in Sandbox

chocolatepie33
Support Team
Support Team
Posts: 2458
Joined: April 27th, 2010, 5:31 pm
IRC Username: CP

Re: Models vs. Performance

Postby chocolatepie33 » November 2nd, 2012, 6:51 pm

kddekadenz wrote: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.
Julius wrote:Contribute to http://www.opengameart.org NOW!

Save the wiki!

Hirato
Developer
Developer
Posts: 689
Joined: May 30th, 2009, 1:23 pm
IRC Username: hirato

Re: Models vs. Performance

Postby Hirato » November 2nd, 2012, 8:26 pm

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:
This is not a url, clicking it is pointless

User avatar
kddekadenz
Member
Member
Posts: 423
Joined: July 17th, 2011, 11:02 am
Name: kdd
Contact:

Re: Models vs. Performance

Postby kddekadenz » November 3rd, 2012, 8:01 am

Yes, I have to get a new computer :lol:
Nevertheless models and entities do slow down the game a lot. I think Tesseract will eat some performance, too.
Kelgar is an advanced RPG beeing developed in Sandbox

chocolatepie33
Support Team
Support Team
Posts: 2458
Joined: April 27th, 2010, 5:31 pm
IRC Username: CP

Re: Models vs. Performance

Postby chocolatepie33 » November 3rd, 2012, 2:45 pm

kddekadenz wrote: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?
Julius wrote:Contribute to http://www.opengameart.org NOW!

Save the wiki!

User avatar
Runescapedj
Member
Member
Posts: 1706
Joined: January 9th, 2010, 9:06 am
Name: Michiel
IRC Username: Sandboxdj
Location: Deventer, the Netherlands

Re: Models vs. Performance

Postby Runescapedj » November 3rd, 2012, 4:29 pm

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
Support Team
Support Team
Posts: 2458
Joined: April 27th, 2010, 5:31 pm
IRC Username: CP

Re: Models vs. Performance

Postby chocolatepie33 » November 3rd, 2012, 6:12 pm

@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? :roll: ), 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.
Julius wrote:Contribute to http://www.opengameart.org NOW!

Save the wiki!

Hirato
Developer
Developer
Posts: 689
Joined: May 30th, 2009, 1:23 pm
IRC Username: hirato

Re: Models vs. Performance

Postby Hirato » November 3rd, 2012, 9:45 pm

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))
This is not a url, clicking it is pointless

User avatar
Captain_Ahab
Member
Member
Posts: 98
Joined: June 10th, 2009, 5:12 pm
Name: Richard

Re: Models vs. Performance

Postby Captain_Ahab » November 3rd, 2012, 10:16 pm

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?
Image

Hirato
Developer
Developer
Posts: 689
Joined: May 30th, 2009, 1:23 pm
IRC Username: hirato

Re: Models vs. Performance

Postby Hirato » November 3rd, 2012, 11:02 pm

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.
This is not a url, clicking it is pointless


Return to “Sandbox General Support”

Who is online

Users browsing this forum: Bing [Bot] and 4 guests