Assets Obi Particle Based Physics (Cloth, Rope, Fluid) thread

Hi, I've bought obi cloth for a long time, just got the chance to test it and try to integrate it into my project.
I'm using UMA character system, and I've found a post in this thread back in 2016 about UMA compatibilities.
Here is my question: is UMA officially supported in current version or it requires ourselves to integrate it?

 

Hi,

There's no official support for UMA as of now, you'll have to integrate it yourself.

 

Ok, any further suggestions for the integration apart from the post I've read?
Or anything changed may make that approach unavailable?
Thank you for your time

 

If you want/need bone deformation customization in UMA then it won't work with obi cloth. That's the problem I ran in to. Obi cloth (and unity/nvidia cloth ) assumes 1,1,1 scale of the bones affecting vertices. If not, the cloth simulation will be off. In UMA 3, we're planning to have the bones and vertices get baked back to 1,1,1 so then cloth simulations will work properly.

 

Thank you for the info, I guess I'll wait for the new UMA version then

 

@arkano22
I'm setuping a new project in 2018.2 (.10) and some #defines fail to apply upon import:
(windows 64 editor, Windows x86_64 target platform in build settings)

PlayerSettings Validation: Requested build target group (20) doesn't exist; #define symbols for scripting won't be added.
PlayerSettings Validation: Requested build target group (17) doesn't exist; #define symbols for scripting won't be added.

Does it have some repercussion which should I be aware of ?

These two error messages are appearing in the console once in a while as well:

one 'organizational' issue - sorry I refuse to register on a new support forum per each asset I own, so hopefully posting here a support question is a.ok

Thanks!

 

Hi there,

It's ok to post here, but the downside is I only check the Unity forums once in a while. The official forums are checked at least once everyday. (edit: however we do not answer support questions in Facebook, Youtube comments, or asset store reviews)

The first two errors shouldn't be a problem. They refer to a sample script (which is not part of the core system, only used in one of the sample scenes). I will check it for compatibility with 2018 in the next release.

The second pair of errors are a bug in Unity, fixed in 2018.3
https://issuetracker.unity3d.com/is...be-checked-because-doesnt-exist-error-message

 

Thanks!

 

@arkano22 I would have a bug to be fixed for you -

please move the

Code (CSharp):

1. int i = 0;

counter in ObiParticleActorEditor.cs, Ln 340 inside the particle drawing cycle ( e.g. to line Ln 350 )

I suppose you've never encountered it with small vertex count models ( the drawcallCount count never something else than 1 )
I *think* this should fix it.
Thanks !

 

I would also appreciate if you could look into saving times in the editor (which are getting ridiculous with few semi complex models)
E.g. I have 9 models in prefab testing scene, all disabled game objects; (all with its own SkinnedMesh renderer, ObiCloth, each its own solver);
One exceeding 25000 vertex count, the rest having in about 10000 vertices each
When I press ctrl+s to save the scene it takes about 20 seconds for unity to come back - I wonder what's going on there since everything is already saved manually.
There's nothing else of significance in the scene, i.e. if I remove the prefabs it saves instantly.
As you can imagine it's easier to adjust things having them all in there instead of dragging and working with each individually. (That's on i7 3.4 GHz CPU, on SSD, W10 64bit)

 

The sync between computed data and unity game object references is not ideal either:
E.g. if you copy the cloth component and 'paste component as new' on another game object it retains solver and topology references (which is fine), but dragging new solver, topology and having Initialize run doesn't completely wipe out old data - the mesh was deformed for me.
I *think* unity restart might have solved this, but as you can imagine that's not an option - I had to setup each game object with new component individually.
^ the above is not critical issue, but please consider it (alongside previous post) as _very_ welcome quality of life improvements

Thanks!

 

Unity re-serializes all objects and components in the scene when you save it. It does not (afaik) keep a per-object dirty flag, but flags the entire scene as dirty when anything in it changes, so it has to serialize everything each time you save.

In the case of cloth instances, it has to serialize a lot of per-particle data (position, velocity, radius, skin backstop values, mass, etc) and per-constraint data (stiffness, particle index pairs, etc). For +115000 (!) particles in your scene, this can be quite a lot. My advice would be saving them as prefabs and instantiating them at runtime.

Note that we cannot use particle instancing, as each object is susceptible of having its own per particle mass, radius, positions, velocities (due to per-object rest state support), etc. So no way of reducing the amount of serialized data without losing functionality.

Anyway, such huge cloth meshes will probably bring performance to its knees. Consider using proxies. A 25000 vertex mesh should never be simulated directly unless you really need high resolution cloth (certainly not for a game, unless you're doing something else which does not need to run in realtime). A 2000 vertex mesh simulation can drive it just fine.

 

I have them as prefabs, I was talking about modifying the prefabs in the test scene

Anyway in this case you might be correct since the dirtying any game object in any way triggers reserialization of the whole scene along all data
As I mentioned the workaround is to modify each prefab/instance individually by single dragging it to the test scene

No I won't, at least for now - each model resp. prefab individually works: as I mentioned in average it's 10k vertices/model (+ unoptimized, and only about half unfixed) which is more than acceptable at runtime

 

Another bug which triggers randomly for me is that occasionally after working with cloth components and entering Play mode, the mesh of the skinned mesh renderer shifts upwards - outside of the skinned mesh renderer bounds - the bounds are staying at correct place; I *think* the simulation is shifted too

Re-Initialize seems to fix it ( time consuming as it might be with 10k vertices )

 

When having more than one cloth actor in the scene and editing particles on one it happened that the selection of particles carried over to when editing the next one
- this one doesn't seem to trigger once there are already exiting previously created particles/fixes on the component (e.g. when editing prefab) - but I'm not sure

Nothing which couldn't be undone by hitting clear selection first for sure - just had to be aware

 

That's probably it after working for about 2 days with it
Other than that the simulation works great ! ʘ‿ʘ

One must be just careful when tweaking/modifying the parameters afterwards -

 

One more thing:

allow the package (or please verify that it is/not possible) to be moved freely anywhere in the project such as Plugins folder

(which currently didn't work for me throwing various errors until I moved it back - restart might have helped or something, didn't research this further)

 

If user changes other - *non* obi* - component on go/prefab with obi* attached, the whole dirtied object is serialized
- which lead to points re/serialization (which, as in the cases above prolongs saving times)

Good practice in these cases is to keep data/points in a separate scriptable object in the project and updating them separately only per user direct obi change / indirect obi request when needed only

This will complicate architecture for sure, but might lead to more comfortable workflow with obi* components

 

@arkano22 I'm getting a red flag with the latest download: Menu Component/Physics/Obi/Obi Particle Renderer can't be checked because doesn't exist

 

Bug in Unity, can be safely ignored:
https://issuetracker.unity3d.com/is...be-checked-because-doesnt-exist-error-message

 

Hi all,

I've been working hard without leaving my cave for a few months now. Obi 4.0 is almost ready, and with it, a lot of new stuff, improvements to classic stuff, and of course bug fixes. Only a few more weeks to go, during which testing will take place.

4.0 will only work for Unity 2018.1 and up. Here's a sneak peek of what's new for ropes, fluids, and a 4.0 newcomer: Obi Softbody.

Obi Rope

A new kind of actor has been added to the pack: Obi Rod. Rods are similar to ropes, but have a few key differences:

• They model shearing and torsion, coupled with bending. This allows them to simulate a lot of real world phenomena that ropes cannot.
• Anisotropic bending/shearing/torsion stiffness, independent of timestep and iteration count (uses XPBD)
• They remember their rest shape, and can be made rigid.
• They are completely inextensible.

So while ropes are merely a list of points chained together by distance constraints, rods use something called Cosserat rod theory to model a solid, elongated piece of matter.

Pricing for new users will go up a little bit (around 5$ more), but if you already own ObiRope, updating is completely free.

Obi Fluid

• Faster core solver, specially in mobile devices (around x1.5).
• Much faster particle advection (x2).
• Better, unconditionally stable surface tension model.
• No limitation in the amount of particle neighbors.
• Per-particle properties: vorticity, viscosity, resolution...
  
• Multirresolution fluids (ability to mix fluids sampled at different resolutions).
• Property diffusion.

Pricing stays the same, so you pay the same regardless of when you purchase Obi Fluid (before or after the update).

Obi Softbody

An entirely new Obi asset dedicated to simulate rigid and softbodies. Makes use of oriented particles to achieve unconditional shape matching stability, and outstanding speed. You can turn complete meshes into a softbody literally at the click of a button (even non-manifold meshes). Softbodies track their transform position and orientation, so for the most part you can treat them as a regular object. Softbody-fying works with any part of a skinned mesh too (beeeewbs ).

Price-wise, it will sit somewhere between Obi Cloth (45$) and Obi Fluid (60$).

Hope you like it, find it useful and make awesome stuff with it!

 

"Softbody-fying works with any part of a skinned mesh too (beeeewbs )."
If I no wrong understanding, that's you mean "boin boin" for chest and hip physic .... ( Man Romance )

 

Yep. Loved your comment, by the way.

 

Ok - just to confirm, you're adding softbody and rigid ropes, exactly what I haven't been able to find a good solution for?

Color me excited, already own rope and cloth. I'll definitely look at softbody, but the Rigid Ropes (Rod) solution sounds perfect for a car antennae which I was struggling with this week. - I look forward to the 4.0 release.

Don
have a great day

 

Amazing stuff!

 

Soft bodies would be a different asset. It's a world on its own...

 

Pretty sure that the announcement of: "Obi SoftBody" will cover that part - I'm excited about both new features

 

Hello! We have a lot of skinned mesh clothing in our game. We've been using unity's own cloth (which is horrible to set up and looks rubbish), and recently tried switching to obi cloth and were very impressed by the results! I'm just checking in to enquire about the status of the xbox one support? We would love to use obi in our game, but xbox support is critical for us.

 

Hello,
I am developing a ship bridge simulator of big ships (i.e. container carriers ), I would like to use your Obi Rope to model the anchor. Before to buy the package I would like to be sure that the rope will not stretch if I will move the ship using a force of 11*10^6 Newton.
Thank you

 

Hi there (I already answered your PM, but I'm pasting the answer here if it helps anyone else)

Obi is not designed (or meant) to be used in an industrial simulation environment. These simulations generally have much higher accuracy and stability requirements compared to game-grade simulators.

This is specially true when dealing with huge mass ratios, or extremely large forces like in your case. These are very uncommon in games and to be solved in a physically accurate way they require a fundamentally different approach. (Read on iterative vs direct solvers if you want more technically oriented information).

I'd recommend using an engineering grade simulator, like AgX, which includes a realtime direct solver:
https://www.algoryx.se/products/agx-dynamics/

 

How can we make Soft Bodies ?