Not really sure where to put this

[Ffcloud]

anyways, i know that everyone that has or is playing MB is having problems w/ framerates so i have come up w/ a solution(i couldnt program it, im not that good yet).  Most people have heard or have played Half-life or a mod for half-life and know that you cant see all the way accross the stage like in MB b/c half-life has visibility settings when you make a map. also in GTA:VC for PC there are visiblity settings if your computer cannot handle seeing all the way accross the town. basically what im getting at is that if the devs of PS were to incorporate some sort of visibility setting so the game werent trying to show the whole town at one time then it would probably run faster on many computers. I have a high end computer(very high end) and i even have trouble sometimes w/ framerates on MB. also it seems that MB trys to display things on the screen when they cant be seen, like trying to display the church through a wall. but you wont see this being done b/c the wall is closer. am i making sense? are any of these things already in MB? am i just an insane computer freak that has nothing better to do with his time? oh well...

[dfryer]

Some of these things (like not drawing the whole city when you\'re facing a wall) may be addressed by the next release.  Using the MB hydlaa map on my Mac in the crystalspace \"walktest\" application, I get \"decent\" framerates (10-40 fps) considering my graphics card (a geforce2MX on a 700mhz Mac).  In the real game, this will be slowed down somewhat, but it\'s a lot better than with earlier versions of the CrystalSpace engine.

The artists/developers have expressed some reluctance when it comes to fogging things out, but I agree with you in that it could possibly improve performance to cut out distant geometry altogether as a last resort.  There are other techniques that can still be explored, and the focus of the current series of releases is not so much on speed but on getting the \"game\" working.  Crystal Space (and planeshift) will continue to improve.

[Cyrandir]

Just to put my two cents worth in, I agree that fogging should be an option for people.  The ability to play the game on many grades of hardware should be a priority as it maximizes the potential size of the community and the overall quality of the program.  Some kind of optional, variable-distance fogging system should be implemented in a future release.

[jorrit]

Note that fogging as such does not improve performance. On the contrary. It is an additional thing to render (fog) so it even decreases performance. However, fog in combination with far plane clipping (where you simply don\'t render objects that are far away) can actually improve performance.

The new renderer does not support fog yet (that\'s still a todo) but far plane clipping is fully supported. I will talk to the engine team of PS to see if this could be put in optionally. If not it is rather easy to hack it in later with some client mod :-)

Greetings,

[tangerine]

Ok this thread led me to implement limits on visible distance in PS. You will be able to either
a) set the distance limit
b) set the fps you want to maintain (and the distance will be set automatically)

Wait for CB

[lynx_lupo]

Great Tangerine!! :diamond:

[jorrit]

Today I tried tangerine\'s modifications to the camera system in Crystal Core (which uses the same movement and camera system as PS) and it works great. You can either set a fixed clipping distance or else use an adaptive system in which the engine will decrease or increase the clipping distance based on desired minimum and maximum fps. If you set this minimum fps too high then of course you will get visible objects that disappear but then of course, you can\'t get more fps without some sacrifice :-)

Greetings,

[lynx_lupo]

How would this adaptive one react on many sudden changes, like lag caused by new players, things that pass your way etc etc? Would you get an annoying \"animation\" of the cliping plane moving up and down(horizontally)? Or is there some minimum time for changes to take place?

[jorrit]

Originally posted by lynx_lupo
How would this adaptive one react on many sudden changes, like lag caused by new players, things that pass your way etc etc? Would you get an annoying \"animation\" of the cliping plane moving up and down(horizontally)? Or is there some minimum time for changes to take place?

It adapts relatively slowly so the changes are not sudden. Of course, appearing/disappearing objects are sudden no matter how slowly you do that so the effect is not THAT nice.

Greetings,

[tangerine]

I don\'t think the adaptive mode is that great it is usable but it certainly needs more work. The adaptation is often slow, it can take time before it settles on the configured fps and sometimes you can even see the distance limit fluctuating, which means that objects close to the long-term clipping boundary are repeateadly appearing and disappearing even when you are standing still. Another problem is that meshes are either 100% visible, or not at all. The result are abrupt changes in the landscape or even holes in it. One solution could be to improve CS so that the clipping plane cuts meshes in half rather that the \"you see either everything or nothing\" way. Or we could put fog to vincity of the plane, or we could make meshes approaching to the clipping plane gradually transparent.

But I am sure it will be useful even in the present state and people with worse computers will gladly sacrifice part of the eye candy to have decent framerates in maps like Hydlaa.

[Cyrandir]

I would like to take this moment to thank the devs for taking this idea and doing something with it.  It\'s been really nice to get dev feedback on an idea and to see it implemented with all speed.  Thank you Devs!

[tangerine]

Originally posted by lynx_lupo
How would this adaptive one react on many sudden changes, like lag caused by new players, things that pass your way etc etc? Would you get an annoying \"animation\" of the cliping plane moving up and down(horizontally)? Or is there some minimum time for changes to take place?

It\'s not nice but there is room for improvements. I think it\'s quite hard to estimate the right distance. Currently the game measures difference between requested and actual fps - the greater is this difference, the greater is the distance adjustment.

I also tried to estimate the fps/distance ratio and use it to predict how will fps change when I change distance by X. But the fps is too chaotic and the distance-versus-fps relation is really too nonlinear to get something reasonable. Also when you turn around, the distance-versus-fps relation changes very much.

I am thinking about more complex system that is collecting data and fits the (nonlinear) fps-versus-distance curve and uses it for adjustments. But that has low priority.

Distance is currently adjusted every 2 seconds (when fps is outside configured interval). The code is in src/client/pscamera.cpp in method AdaptDistanceClipping()

[lynx_lupo]

I agree - it\'s awkward now. I\'ll probably use, if i\'ll have to, the fixed distance one anyway.

Couldn\'t you accelerate the FP view very much with clipping planes? You can clip out more than half of the world... FP would be the fastest view.

[dfryer]

Whether you\'re first person or third person, pretty much anything outside the \"camera\" (or the view frustum for that matter) is being clipped, so it shouldn\'t really matter.  In fact, a floating camera is probably looking more in the downwards direction and so is less likely to see as much detailed geometry in the distance.