(11-10-2018, 04:27 AM)int0thewind Wrote: Hey Jose,
I've seen some Youtube videos and read some documentation about optimization. I'm curious if you could elaborate in anyway about optimizing any further? For instance, about a month ago I had contacted you about fixing a cape I was attaching to a character. That cape had quite a few white dots, are those representing mesh vertices? The game running inside unity would run around 300 fps, after I had the cape attached and working, it went down to 140 which is quite a hit. I'm not sure if i'm doing something wrong? Please let me know if you have any feedback and I greatly appreciate your software package and your time. Thanks.
Hi there,
Obi generates one particle per mesh vertex (after fusing together vertices at uv, color, or normal discontinuities). These can be viewed in the particle editor, or at runtime by adding a ObiParticleRenderer component to the cloth. These are also used for collision detection (both against colliders, and self-collision). You can view them as small "atoms" that make up your cloth.
Broadly speaking, as the vertex count in your mesh goes up, you need to perform the simulation more often to keep the simulation quality constant. This can be done by either reducing the
fixed timestep (will cause Unity to update physics more often, see:
https://docs.unity3d.com/Manual/class-TimeManager.html), increasing the amount of solver
substeps (will subdivide each fixed timestep into a number of smaller steps) or by increasing the amount of
constraint iterations in the solver (will update the constraints between particles more times per substep).
So optimization usually is a matter of finding the sweet spot between:
mesh density (less = better performance).
fixed timestep (more = better performance).
substeps (less = better performance).
iterations (less = better performance).
This is true not only for Obi but for pretty much any iterative physics engine in existence.
Note that if you need a lot of visual fidelity in your mesh, but do not require/want to simulate a high-definition mesh, you can use proxies. This will allow you to use a low-res mesh to drive a high-res one:
http://obi.virtualmethodstudio.com/tutor...oxies.html
Also, never measure performance using fps. Use milliseconds/frame. The reason for this is that fps do not scale linearly: the performance jump from 300 to 140 fps is actually very small (from 3.3 ms/frame to 7 ms/frame, just 3.7 ms more). Going from 60 fps to 20 fps however, means 16 to 50 ms/frame (34 ms more). The usual budget for a 60 fps game is 16 ms/frame. Physics generally are given 5-7 ms of this budget.
