Hi! Welcome to the forum for Platinum Arts Sandbox Free 3D Game Maker. I currently have the forums locked as I am attempting to properly update them.
In the meantime please join the new Discord Server!
If you have any questions please e-mail me through the Platinum Arts website.
In the meantime please join the new Discord Server!
If you have any questions please e-mail me through the Platinum Arts website.
Models vs. Performance
- kddekadenz
- Member
- Posts: 423
- Joined: July 17th, 2011, 11:02 am
- Name: kdd
- Contact:
Models vs. Performance
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
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
Kelgar is an advanced RPG beeing developed in Sandbox
-
- Support Team
- Posts: 2458
- Joined: April 27th, 2010, 5:31 pm
- IRC Username: CP
Re: Models vs. Performance
So you're suggesting the variable defines the maximum viewing distance and changes based on average fps, or actual distance?kddekadenz wrote: So the way to fix this is a static variable defining the maximal view 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!
Re: Models vs. Performance
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:
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
- kddekadenz
- Member
- Posts: 423
- Joined: July 17th, 2011, 11:02 am
- Name: kdd
- Contact:
Re: Models vs. Performance
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.
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
-
- Support Team
- Posts: 2458
- Joined: April 27th, 2010, 5:31 pm
- IRC Username: CP
Re: Models vs. Performance
Why is everyone talking about Tesseract all of a sudden? Was there some event I missed out on?kddekadenz wrote:I think Tesseract will eat some performance, too.
Julius wrote:Contribute to http://www.opengameart.org NOW!
Save the wiki!
- Runescapedj
- Member
- Posts: 1706
- Joined: January 9th, 2010, 9:06 am
- Name: Michiel
- IRC Username: Sandboxdj
- Location: Deventer, the Netherlands
Re: Models vs. Performance
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
-
- Support Team
- Posts: 2458
- Joined: April 27th, 2010, 5:31 pm
- IRC Username: CP
Re: Models vs. Performance
@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:
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.
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]
]
Julius wrote:Contribute to http://www.opengameart.org NOW!
Save the wiki!
Re: Models vs. Performance
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.
@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
- Captain_Ahab
- Member
- Posts: 98
- Joined: June 10th, 2009, 5:12 pm
- Name: Richard
Re: Models vs. Performance
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?
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?
Re: Models vs. Performance
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.
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