(06-08-2019, 02:36 AM)MasterGeneralB Wrote: I found out the hot-loading soon after some more internet digging.
It's the first time I hear of bars in obi-ropes... so I will definitely take a look into that! (I got ropes before the 4.0 release). My main disappointment was when you have a rope running over say a pulley wheel and it is attached to an object. The rope doesn't display tension, it looks like a bouncy wet noodle (a real rope would slightly stretch linearly and eventually rip/break from too much weight), it looks like it lacks strain on it. A heavy enough weight on the end of a rope should swing in a perfect arc and be unable to bounce around since the rope has enough tension on it to keep it straight all the time rather than jump and bounce around. I tried mucking about to attempt to remove ALL of the springiness in the rope but I didn't dive deep into it (it wasn't a necessary thing, so I shelved the whole rope thing).
Well this is basic stuff, as in inherent-to-computer-simulation basic. Let me explain:
In physics, there are basically two kinds of solver:
direct and
iterative. Direct solvers are very slow but precise (in big O notation: O(n^3) in the number of equations). Iterative solvers can either be precise or fast (O(n x iterations)). 99% of realtime physics engines use an iterative solver, Obi is no exception.
It is near-impossible to remove
all springiness in any constraint system using an iterative solver . This is a fundamental consequence of how solvers work: they repeat (iterate) a very fast calculation over all constraints, reducing the overall error a little bit each time. So they approach the ground truth solution slowly, but outputting a useable result every step of the way. The more times you
iterate, the smaller the
timestep is, the smaller the equation
system is, or the closer to 1:1 your mass ratios are, the faster they will reach the solution. The speed at which the solver approaches the solution is called
convergence speed.
When the system hasn't fully converged -because you use very few iterations, a large timestep, or large mass ratios- the error can show up as jitter, stretchiness, or things blowing up in crazy ways (
ever tried a largish joint system in Unity?). Obi is unconditionally stable, which means you have a
no-blowup guarantee and the error will always manifest itself as stretchiness. This alone is a huge advantage over classic solvers.
In Obi, this translates as:
- Reduce rope resolution to have a smaller equation system, and improve convergence.
- Reduce Unity's timestep (or increase the amount of solver substeps) to improve convergence.
- Use more iterations to improve convergence.
- Reduce mass ratios to improve convergence. Rule of thumb for most realtime solvers is
do not exceed 1:10. (That is, at most you can hang a 10 kg weight from a 1 kg rope, or a 100 kg weight from a 10 kg rope). Excerpt from PhysX's docs:
Quote:The solver can have difficulty converging well when a light object is constrained between two heavy objects. Mass ratios of higher than 10 are best avoided in such scenarios.
https://docs.nvidia.com/gameworks/conten...oints.html
Now, for the very specific case of pulley systems, we have a specialized solution called Filo. It works by constraining the pulleys themselves directly, instead of simulating a distance and contact constraint system. As it uses far fewer constraints, it converges much faster (but has its own set of limitations):
https://assetstore.unity.com/packages/to...tor-133620
(06-08-2019, 02:36 AM)MasterGeneralB Wrote: As for the fluid system, I am fully aware. I was just expecting to have the demo scenes somewhat workable at a steady frame rate (maybe 30-45 fps) to showcase the system. I understand the limitations for accurate fluid simulations but my intention was to use it on a small scale and in 2D.
What I don't understand is if it is normal for the 2D version to cause such a low frame rate... I have no issue lowering the time-step and preventing a death spiral on something I plan on uniquely building... but (and this is legitimately not a rhetorical question) should the demo scenes really be running at such a low frame-rate without tweaks to my unity build? If the answer is a yes, I can work with that, I'm just surprised.
It depends. If your project settings are causing a death spiral, (the default max timestep is 0.33, which can cause physics to be updated
sixteen times per frame) then it is possible to get 4-5 fps. All scenes are meant to run at a reasonable fps (60-200, depending on the scene), assuming 1 to 2 physics updates per frame in a moderately powerful CPU. Also, (I cannot stress this enough): make sure to profile in a standalone build, not the editor. The difference in performance is huge.
(06-08-2019, 02:36 AM)MasterGeneralB Wrote: I need to use obi fluids for small scale fluid dynamics in my game and I will be very selective as to how many particles I use as well as disabling/destroying them off-screen etc... as long as I can do that without frame rate dropping to less than 50 fps, I think I can deal. But if all I have is a small glob of 200 particles on screen and it tanks my frames to 12fps, then I can't do anything with.
There is either something very wrong in your Time settings, or your computer is just not powerful enough. Try setting your fixed timestep to 0.02 and your max fixed timestep to 0.04. Most scenes should run above 60 fps in a decent CPU. See our performance benchmarks:
http://obi.virtualmethodstudio.com/performance.html
