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

EDIT:

This is a long thread covering all updates on all Obi Assets currently available on the asset store.

See all of them in our website: http://obi.virtualmethodstudio.com


----------------

Hi all!

I´ve been working on this:

<<-Video not available anymore->> Find our youtube channel here: https://www.youtube.com/c/VirtualMethod

It´s a full implementation of the original paper (http://matthias-mueller-fischer.ch/publications/posBasedDyn.pdf) that spawned the old PhysX cloth, adding a few improvements on the way: triangle-based bending constraints instead of dihedral angle constraints, better friction model, better self-collisions, virtual particles for rigid body collisions just to name a few.

I really needed to get the old cloth physics working in Unity 5.x for a project i'm developing so I hope this will help those with the same need. Will be available on the Asset Store in a few days for a low price (around 20$) and with full C# source included, i'm just finishing up the documentation and tidying up things.

Suggestions are welcome, my current roadmap for this in order of priority is:

• Multithreading
  
• Ability to drive a transform using a particle or group of particles.
• Proxy lattice system to drive hi-poly meshes using a low-poly simulation.
  
• Rope physics with LRAs (long-range attachments)

Cheers!

 

Well if you need it stress tested on about 200 objects in a sailing game, count me in!

 

Well that is a good stress test indeed!. We'd probably need some sort of simulation LOD system to accomplish that though. Not a good idea to simulate all 200 sails at full detail even if they`re all at once on screen.

Adding that to the roadmap!

 

Looks awesome my friend keep going!

 

looks good, quite a few people need old cloth back, that can simulate with wind... including myself

 

I will be interested how it handles double sided meshes. The current U5 cloth just craps out on the double sided normals and makes the cloth go completely screwy.

 

When you talk about double sided meshes, are you referring to "thick" double sided meshes as in two sets of faces with normals in opposite directions, or a double sided material for a single-sided mesh? If it is the latter, there's a double sided version of the Standard shader included that reverses normals for the backfaces, meaning you get correct lighting on both sides of your mesh.

Having double sided meshes ("thick" geometry) simulated as-is is no good: It means twice the geometry and forces you to have self-collisions turned on to avoid interpenetration, which skyrockets the computational cost. You could use a single-sided mesh simulation as a proxy, using its results to drive the movement of an arbitrarily complex mesh. That ability will come in an update.

 

You can make a mesh with the faces on both sides so it is still a single set of vertices but two faces. Mind you, I am not a modeler but the modeler for our group showed me how that worked with normals going in both directions of a face. Knowing the computation cost on using two distinct faces, there is hardly another option since all of the single sided shaders that render double sided do not allow for things like SSAO to work since it renders right over them. A lot of those post process effects will render on top of the backside of a single sided mesh with double sided shader so it just kills any cloth rendering. Example: http://puu.sh/ilvza.png

I was able to get our bidirectional normal mesh to work, but the built in Unity cloth component split it up into two separate meshes and made it go completely crazy. Static, however, it looks great because it does not allow the SSAO effects through the object.

 

Wow, that sounds a lot like non-manifold geometry. Which is bound to cause problems in a lot of rendering and simulation situations.

I would recommend doing the following: assign two materials to the same mesh: one renders front faces, the other renders backfaces with flipped normals. Most "double sided" materials actually do not flip the normals, so a lot of lighting/shadowing computations (like SSAO) look funky or just stop working. I can do this for you if you want, test it out and tell me the results.

 

Here. This is a Standard shader variation that automatically renders back faces with correct lighting/shadowing. Haven't tested it with SSAO but should work fine.

www.josemariamendez.com/storage/BackfacesShader.zip

Grab any single-sided mesh, set the Materials array size to 2 in the editor, and assign a material with this shader to the second slot. The first one should be your regular front-faces material.

This also allows you to have completely different looks to your front and back faces.

 

Great, thanks! If this works then I will have to get the Rust team to add it to Alloy since that is how we are doing the transmission shading on the sails.

 

That is closer than I have been so far! Now to just get that function working in Alloy and it will be good to go.

 

Great! I haven't used Alloy, but the theory should be the same: two materials, a regular one and a second one that renders backfaces (Cull front) with the normals flipped (multiplied by -1).

 

Hi
I can apply the physical fabric of the bottom of a jacket with this tool?

 

Yes you can. Just assign a cloth component to the jacket and pin those vertices that you don't want to simulate.
Once the tool is out (currently being reviewed) I will publish a few tutorials explaining how to perform common tasks with it.

 

Magnificent, i wait this asset

 

Oh my. I just spent a week creating a procedural bone-based system to simulate ad-hoc cloth vertex anchoring the way it was done in <5.x with attached colliders. And it's really shoddy. So I'm going to be heavily on board with your plugin the moment it's out.

 

@daterre ... it came out yesterday.

https://www.assetstore.unity3d.com/en/#!/content/40758

 

Hi everyone,

The plugin came out yesterday as Hopeful just pointed out, though an update is already on its way. The update features:

- Adjustable world velocity scale, so you can fine tune how much of the character movement translates to the cloth. This is a must have for character clothing, so there you go.

- Independent solver iteration amount controls for each kind of constraint. This allows you to solve stretch constraints 5 times per frame, while solving bend constraints only 2 times, for example. The solver automatically interleaves them so no biasing is introduced due to evaluating each constraint a different amount of times.

- Parallel constraint solving mode (warning: nothing to do with multithreading!), which cranks up stability, at the cost of convergence speed. Sequential mode (which most solvers use) is available too.

I´m at full speed writing documentation and examples/tutorials now!

 

Good job arkano22 on this cloth asset! It would be a great addition to my game, but I got one question first: does it work with animated characters?

If yes, It would be cool if you could add simple skinned mesh renderer demo and show how to connect cloth vertices to it.

 

Hi Martin, and thanks!

SkinnedMeshRenderers are not supported directly yet (i'm working on it), but you can attach cloth vertices from a separate object to a character, and it will collide with any colliders you set up in your character transform hierarchy.

So, it works great for things like capes, shrouds, scarfs... anything that is not skinned to the character's bones. Not good for tight clothing like pants, shirts and stuff.

Anyway, right now you are much better off using Unity 5's integrated cloth solution for this because it is designed specifically for this purpose.

 

Duu

Duuuuude...yessssss!

 

Here you can see cloth self-collisions in action (already included in current Asset Store version) and the upcoming distance-field based collisions.

Distance field collisions allow the cloth to collide with arbitrary geometry at very very little cost. A preprocessing step is performed in-editor for each mesh the cloth will be colliding with, after which collisions are lighting fast even for massive meshes. All precomputed data is adaptively sampled and compressed, which means that the "interesting" parts of the collision mesh are given more attention while boring/flat parts produce very little data. Collision meshes can be moved around, rotated and uniformly scaled in realtime, and can be rigid bodies.

Furthermore, this collision method will allow for LOD collisions: far away objects will automatically use coarser collision detection, while objects near the camera will perform detailed collision detection.

The Stanford dragon seen in the video is made up of 270.000 triangles, however colliding with it is just a bit slower than colliding with a simple cube. No iteration over all triangles is made at runtime. Most of the time is spent in self-collisions.

Hope you find it useful!

 

You're a genius . . .

 

Obi 1.2 is already being reviewed in the Asset Store, should be out in a couple days. New features:

- Terrain collider support.
- Distance field colliders (see the video for a quick setup tutorial).
- Bugfixes.

The Distance Field inspector shows a volumetric previsualization of the field, and also an estimation of its size in terms of memory. Two methods are offered for estimating the field gradient (think of it as the object's normals, used for collision response): a high quality one which is enabled by default, and a quick estimation that saves up to 75% memory at the cost of precision, which is not visually noticeable for complex objects with lots of crevices.

Next version (1.3) will feature particle sleeping, which is just like Unity's rigidbody sleeping: particles with low velocity start to "sleep" and are not updated until some collision or constraint wakes them up. This helps performance a lot when you have cloth objects just hanging there most of the time. Velocity damping will probably be ready for 1.3 too.

 

1.2 Is already out:
https://www.assetstore.unity3d.com/en/#!/content/40758

1.3 will be sent for revision tomorrow, featuring:
- Particle sleeping.
- High-quality velocity damping.
- Physically based aerodynamics model. Current aerodynamics just model drag force, and cloth velocity is not considered at all. The new system models both lift and drag, so a piece of cloth in absence of wind will not fall to the floor like a concrete brick: it will realistically flow, deform and float on its way down.

 

I am still really wanting to test this out, we just aren't in a place to need it just yet. I do have a question, though. We want to be able to furl the sails and I was wondering if that might be possible using this system. Possibly by grabbing the vertices in line above each other and shorten their distance to one another while decreasing their movement. Doable?

 

Is the mesh with distance field collider able to change position and rotation?

 

Hi hippocoder,

Yes, distance field colliders can change position and rotation. Scale can be changed too, but if you deviate too much from uniform scaling (which means that you scale one axis much more than the other two) it will start losing accuracy.

So unless you are doing some crazy scaling, you will be fine.

 

Hmmm, it should be doable. I would do it by either just scaling the whole cloth in one axis (easiest way i think), or by doing exactly what you propose. One quirk of this method is that you will need to identify vertical springs in the cloth (which is trickier than it sounds), then reduce their "restLenght" property.

Although the "scaling the cloth" idea looks awkward at first sight, it actually works nice with Obi since cloth is simulated in the transform's local space.

 

1.3.0 has been submitted for approval. Features:

- Velocity damping.
- New aerodynamics solver, modeling both lift and drag forces. Your cloth will behave realistically even in absence of wind.
- Particle sleeping. Works just like Unity's rigid body sleeping, but per-particle. Particles will go to sleep and won`t be simulated when under a velocity threshold. World-space acceleration, being involved in constraints with awake particles, or collisions with rigid bodies will wake them up.
- Lots of editor speed improvements: Much bigger cloth pieces can be generated in less time, and lots of cloth particles can be drawn in the editor at decent speeds. Distance fields also generate a lot faster.
- Marquee selection of cloth particles in the editor: hold down ctrl while dragging to select a bunch of particles.
- Fixed a bug that prevented cloth creation for certain meshes.
- Cloth Optimization: this little feature will remove all fixed particles that are only connected to other fixed particles from the simulation. This is a no-return operation (unless you re-create the cloth component) that allows you to simulate only certain parts of a much bigger mesh. You can see a real-world use case here:

 

I picked this up this morning. The rendering is impressive, though it might be a bit heavy for what we are doing. I have one question, how can we make projectiles collide with it and tear? I have tried adding to the collider collection but we have pools of hundreds of colliders and I don't think that is very efficient. Possible thinking of using a raycast or something similar to cause the tear manually at a vertex point. Right now with only one ship running cloth (6 sails) it is taking my battle scene from 115fps to a little over 50fps, a second ship takes it down to 24. These are little brigs that only have small sails as well, so the larger ones will completely cripple framerates, I will expect. Might need some sort of LOD type system in it to turn it on/off as far as features go but keep the damaging abilities.

 

Hi Captain!

Glad you liked it. You can fine tune performance using each constraint group "Iterations" property, or by completely disabling constraint groups you don´t need. In your case, all constraint groups except stretch constraints could be disabled, and i think you´ll get away with just 2 iterations for them.

That alone however might not cut the cake. I don't know how dense your sail geometry is, but some stupidly simple LODing could be enough: just disable ObiCloth components that are far away from the camera .

About having lots of colliders, future updates will bring in several broad-phase algorithms that unity doesn't currently expose (kd-trees, bvhs, that sort of stuff) but for now what you can do is use a regular grid where you insert your colliders and the ships. Then, for each ship, you only consider colliders in the same grid cell or an adjacent one. You could even go further and do it sail-wise, instead of ship-wise.

If you need help with this grid i can code a quick prototype for you, just for fun

Edit: Oh, and by the way, make sure you update to 1.3 when it comes out, as particle sleeping might help with performance if your sails tend to stay static sometimes: they will automatically switch off when not changing shape.

 

I have had a bug happen a couple times now. If the sail tears from wind strength during a play test (not in play mode) it causes it to throw errors and can eventually crash Unity. It seems that when it makes the Clone of the mesh that is never resets it back to the original after hitting stop or rewind (which I don't have icons on the buttons BTW). I end up having to disable and reenable the Obi cloth object to get it to fix. Though one time I needed to disable it, restart Unity, then enable it. Not sure what happened there. I will try to get some steps to reproduce.

 

Yep, i´ve reproduced the issue. It has to do with timestep in the editor not being fixed nor clamped to a maximum. It just simulates for as much time as it has passed since last update. With lots of tearing, frames start taking longer to simulate, which in turn forces the editor to simulate more times per frame. More times per frame mean more work to do, which makes the next timestep larger...and this spiral goes on and on until the timestep is Single.MaxValue and the editor hangs . Will release a patch as soon as I fix it, shouldn't take long.

Thanks for spotting it!

 

The bug has been fixed in 1.3.1, which is already under review. Additionally, the editor preview playback is now much more accurate, because the timestep is fixed like in play mode.

 

About not having icons on the buttons, you need to move the /Obi/Editor Default Resources folder to the /Assets folder, as indicated in the quickstart guide.

It is a shame that unity does not support placing editor resources in any other folder, so that's what must be done . If the folder is not a direct child of /Assets, it does not work.

 

Hello arkano22, your simulator looks very cool, how does it work in terms of collision for animated characters' clothing?

 

Hi Minsc!

It can be used for it, but it depends on your specific use case. Its weakest point in terms of character clothing is the lack of support for SkinnedMeshRenderers, which means that if you have your character already modeled and skinned with clothes on, you can't simulate them directly as you would with Unity's built-in cloth. So if this is your case, i'd totally go with Unity's cloth.

However, if you have cloth as a separate, un-skinned object, and you have colliders set up for your character, it works fine.

Currently it's kinda complementary to Unity's cloth when it comes to character clothing. What you can do with it, you can't with Unity, and viceversa. But i'm working to change this .

 

Ok thanks, actually I am currently having cloth as a separate mesh, and with Unity I have to setup a lot of colliders linked to the bones so that the cloth doesn't go through the mesh, I also have to do a lot of tweaking so that it does not seem to collide with invisible walls, is there an alternative process in Obi Cloth? Can I for exemple make the cloth directly collide with the mesh? Or if it is not the case, can I pin some parts of the cloth to the character and make the rest, actually the visible cloth, self collide with the pinned parts so that it looks like the cloth is colliding with the character mesh?

 

The process is pretty much the same as with Unity cloth, you'll have to set up colliders for the character. Colliding cloth with deforming meshes is a big no-no in terms of performance. You can however pin some parts of the cloth to the character and let the rest of the cloth self-collide with the pinned parts. Be warned that self-collision isn't exactly fast to calculate, so if you're doing this for more than a couple characters on screen you're probably in trouble.

Edit: Aaaaand, remember that skinned meshes aren't supported, so the pinned parts of the cloth won't deform along with the character. They must be parented to it, or parts of it.

 

Haha ok looks like there is no easy workaround for this^^, thanks for the info

 

Hi all,

Obi 1.3 was released a few days ago, now working in 1.4. Many of you asked me if the cloth can just collide with everything in the scene, instead of having to use just a few hand-picked colliders. 1.4's biggest feature is the inclusion of the Obi World component, which allows cloth to efficiently collide with lots of colliders, potentially everything in the scene. It is based on a structure called "dynamic AABB tree" or "dynamic bounding volume hierarchy". Here you can see it in action:

 

Unity 5.1.2f1 Pro Win10. Getting these errors on x86 Windows build:


Any thoughts?

 

Whoops! my bad. I forgot to wrap these in precompiler directives.
In CoroutineJob, just remove the "using UnityEditor" as its not needed.
Then, replace your "EditorCoroutine.cs" file with the one i'm attaching.

I will upload a patch for this ASAP. Sorry for the head scratching i may have caused.

 

Thanks for the quick response. We are working toward a release using some of the Obi cloth as a test of some different machines, so we should have some feedback before too long.

 

Obi 1.5 is approaching release, and along with the Obi World component which allows for thousands of potential colliders and the new shape matching constraints that can turn cloth into a rigid body and back, all the collision detection pipeline has been revamped: enter speculative contacts.

Less technically speaking: continuous collision detection is now dirt cheap and always enabled, friction is correctly computed using Coulomb's model and no longer operates on velocities but on positions directly, and self-collisions benefit from both ccd and static/dynamic friction, at zero cost.

Even less technically speaking: stuff can move arbitrarily fast without skipping cloth collisions, and self-collisions are both cheaper and more robust.

 

This looks wonderful! But ... what are the limitations?

 

Well, it depends on what you are using it for. The most obvious limitation i can think of is of course performance. Big, dense cloth objects can take quite a toll on fps. Now that i think of it, I should do a performance chart showing the relationship between particle/constraint number and ms/frame.

As far as drawbacks for this particular technique (speculative contacts), i can see none, at least in the context of cloth simulation. It is easy to implement/maintain, fast, robust...has it all. The famous "ghost collision" bug that is inherent to it is not noticeable at all.

If you want to know if Obi would be suitable for a particular use, just ask me .

 

Well, if the main thing is performance, then how hungry is it?

I'm just trying to get a feel for it. I do realize that if the cloth is still then it gets very efficient, but how much moving cloth is too much?