Help Big (IMO) dip in fps

[alex798]

The FPS Counter script is written for standalone builds and not very reliable inside the editor. You should be using the profiler or the stats window (neither are perfect though, but way better).

I can barely see the profiler pic as it's only 500 px wide, but you seem to be getting over 300 fps.

I oriertiered on counter because didn't know about this issue, Yes with profiler on, and turbo I get results similar to Your mac(still weired), but the matn problem is still dip- because my target platworm is Vive Focus(VR), and it's frame in our main scene is about 60-70, and if each small rope eat 10-20- this is too much for our project(maybe disabling vsync could better situation?)...

[josemendez]

I oriertiered on counter because didn't know about this issue, Yes with profiler on, and turbo I get results similar to Your mac(still weired), but the matn problem is still dip- because my target platworm is Vive Focus(VR), and it's frame in our main scene is about 60-70, and if each small rope eat 10-20- this is too much for our project(maybe disabling vsync could better situation?)...

Never use fps to measure relative performance, use ms/frame. Fps aren't linear, ms/frame are. A 20 fps drop from 90 to 70 is a much smaller performance hit than it is from 40 to 20, for instance.

The solver in that scene uses 20 distance iterations, 10 pin iterations, etc. which are quite a lot. With these settings, simulation takes 0.8 ms/frame (which should take 90 fps down to around 82 fps).

Performance depends on many factors, not just how large the rope is or how many there are in the scene. Solver settings, rendering settings, timestep settings...all have a big impact. Try setting all iterations to 1, then use 2-3 substeps, that should give you 0.5 ms/frame. Also, rendering has a large impact on performance. Using simpler rendering (line rendering, instead of extruded mesh rendering) will take timings down further.

All these are settings/tradeoffs are detailed in the manual:
http://obi.virtualmethodstudio.com/manual/6.2/

Another tip: be mindful of death spiraling. Once you're above a certain ms/frame threshold for physics, performance will go downhill extremely fast unless you reduce your max fixed timestep. This applies to all physics in any engine that uses fixed timestepping, such as Unity.

[josemendez]

This reddit post nicely sums up ms/frame vs fps and how to measure performance (not 100% accurate, but quite close)
https://www.reddit.com/r/gamedev/comment...d_measure/

[alex798]

This reddit post nicely sums up ms/frame vs fps and how to measure performance (not 100% accurate, but quite close)
https://www.reddit.com/r/gamedev/comment...d_measure/

Alright I'll try some configs, thanks for patience- just got rope at friday...thought thay rope from this scene was fitting for our project as is... But could U answer one final confusing situation- I set Blueprint resolution to 1, but particles don't fill curve(no more than 7 particles on 1 meter rope)- what does it mean? And should I return Burst settings(which changed for editor) when I launch standalone?

[josemendez]

Alright I'll try some configs, thanks for patience- just got rope at friday...thought thay rope from this scene was fitting for our project as is... But could U answer one final confusing situation- I set Blueprint resolution to 1, but particles don't fill curve(no more than 7 particles on 1 meter rope)- what does it mean?

Make sure you're changing the same blueprint used by your rope. Also keep in mind that setting the resolution to 1 just means that enough particles will be created for them to overlap at the current thickness. If 7 particles are enough to fill 1 meter with the current thickness, no more will be created. See: http://obi.virtualmethodstudio.com/manua...setup.html

Also, don't confuse particles with path control points. Add a ObiParticleRenderer component to your rope to visualize particles.

And should I return Burst settings(which changed for editor) when I launch standalone?

Burst settings for editor and standalone are different. In a standalone build, the jobs debugger is not used, there's no leak detection, and no safety checks.

[alex798]

Good day, thanks for support yesterday

Could u say if unmoving ropes affect performance (aside from rendering) (and is it possible to correct this? or slightly optimize)

[josemendez]

Good day, thanks for support yesterday

Could u say if unmoving ropes affect performance (aside from rendering) (and is it possible to correct this? or slightly optimize)

Hi there!

Yes, unmoving ropes still need to be simulated. However:

- If the solver is outside any camera's frustum and "simulate when invisible" is unchecked, the entire solver will stop being simulated. See:
http://obi.virtualmethodstudio.com/manua...olver.html

- If you're using decimation > 0 in the rope's path smoother, the mesh will be adaptively decimated (which will result in extremely cheap rendering for straight or close to straight ropes). See:
http://obi.virtualmethodstudio.com/manua...modes.html

[alex798]

Hi there!

Yes, unmoving ropes still need to be simulated. However:

- If the solver is outside any camera's frustum and "simulate when invisible" is unchecked, the entire solver will stop being simulated. See:
http://obi.virtualmethodstudio.com/manua...olver.html

- If you're using decimation > 0 in the rope's path smoother, the mesh will be adaptively decimated (which will result in extremely cheap rendering for straight or close to straight ropes). See:
http://obi.virtualmethodstudio.com/manua...modes.html

Thanks, simulate invisible was very helpful   I presume that Updater is like general multiplier of calculation (for example instead of constains 2 we could set to 1 if we change updater from 1 to 2)?

[josemendez]

I presume that Updater is like general multiplier of calculation (for example instead of constains 2 we could set to 1 if we change updater from 1 to 2)?

Do you mean the updater's "substeps" parameter?

It is kinda like a general multiplier, yes. Basically it takes Unity's timestep and chops it up into multiple smaller sub-steps. All iterations are performed for each substep.

So if you set all constraint iterations to 1 and use 2 substeps, it's the same cost as using 2 iterations and 1 substep. However, substeps yield better quality. Usually you set all iterations to 1 and increase substeps. Then if you need to spend more resources on a *specific* kind of constraint, you use more iterations there.

For a detailed explanation of how the simulation works and what iterations/substeps are, see:
http://obi.virtualmethodstudio.com/manua...gence.html