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

It all heavily depends on the cloth settings, the more constraint groups you have enabled, and the more solver iterations for each one, the slower it gets. Supposing 1 iteration for stretch constraints, which is the absolute minimum to simulate something that resembles cloth, 5000 cloth triangles can be simulated in about 6,5 milliseconds. A second stretch iteration almost doubles that time, and if you start adding fancy stuff (bend constraints, aerodynamics, etc) things of course get slower.

So, my advice is to start with the bare minimum: deactivate everything except stretch constraints, and then start adding stuff while your ms/frame budget allows it.

I'm creating some (pretty complicated) charts so that people get a better idea of what to expect in terms of performance.

Btw, at some point multithreading will be thrown in Obi, that should give a noticeable performance boost.

 

Hi everyone!

Obi 1.5 is now under review and should be out in 4-5 days. Many improvements: physically based friction, self-collision friction, collision with vast amounts of colliders, new continuous collision detection pipeline, shape matching constraints, better aerodynamics, tons of bug fixes... and support for SkinnedMeshRenderer. Which means you can finally add cloth to your characters directly!

Suggestions are welcome. My current roadmap now is:
- Editor brush/paint tool to quickly set up per-particle properties (mass, skin thickness, etc).
- Inter-collisions (having two different pieces of cloth collide with each other).
- Quadratic mode for shape matching constraints.
- Multithreading.

 

Hi I just bought this today. I followed the quick start guide of moving the editor folders but it is still complaining that some of your scripts in your scripts folder also require unityeditor. It seems to be the ones in the scripts coroutine folder. As a result it works fine in the editor but won't let me compile any projects with it. How do I set it up so I can actually compile a project rather than just run it in the editor ? Thanks,

Ian

 

Go back a page. I asked about this a few days ago and a fix was posted. Hope that helps.

 

Thanks CaptainMurphy I've got it working now. One thing I have noticed though is that some of the demos don't run on android. The basic flag does but in the case of the softbody ball the ball just stays still in the air without any collision detection. Any idea why ? I assumed it would all run but just about 3 times slower on my phone than my pc.

 

Hi Ian,

There's no significant difference between these scenes (Obi is all based around constraints and the code is pretty similar for them all), so there's no easy way to tell what's going on. I haven't tried to run the scenes on Android though, so I will and report back any findings / fixes.

Have you tried to check the logs using adb/logcat? Is there any error popping out?

 

By the way, i'm building a webpage for Obi, where I will be adding documentation, videos & more stuff:

http://www.josemariamendez.com/obi/

 

Hi all,

Obi 1.5 is out now, and Obi 1.6 has been already submitted for approval.

1.6 does not bring any brand new cloth functionality like 1.5 did, instead it focuses on editor usability. The editor tools have been revamped, and a lot of new stuff has been added:




Apart from the usual selection tool which allows you to select/deselect particles individually or using a marquee selector, there are two new modes:

• Brush: allows you to select particles using a paintbrush-like tool. You can deselect particles by holding shift while painting.
• Paint: allows you to paint per-particle properties. Right now only 3 properties are paintable: mass, skin radius and skin backstop. More to come. This mode has a lot of goodies you'd expect from a paint tool: can subtract values using shift, selection mask, smooth mode (which can be inverted using shift too, and sharpens instead of smoothing), min/max value cap, etc.

Hope this makes your life easier!

 

Their work is magnificent, increasingly it looks better.

Please when you have time, make a simple example to see how it works in the bottom of a jacket, if you want I can supply the model if you.
It is only a request, if you wish, you can ignore this message, no problem, i do not want to be a nuisance.

 

No matter what settings I use I cannot seem to get the cloth to stop stretching. Quite simply I want something to move with wind vector and interact with a few colliders and that is it and so far it is always stretching regardless of my settings. Any tips?


If I turn off the stretch constraint the cloth just goes into a massive stretch where the fixed points transition to the non-fixed.

 

Looks like I've just found my future hair solution.
This looks like a complete replacement for a built in solution.
I can't wait for Santa to drop this into my digital stocking.

Are there any issues that would make this not work nicely with PlayMaker?

 

Hey CaptainMurphy,

Stretch constraints are there to hold particles together and prevent stretching, so you should (almost) always keep them on. Increasing the amount of iterations on stretch constraints will reduce stretching, but will also reduce performance.

A way to reduce stretching to a minimum is using tether constraints. They're a very cheap way of preventing any stretch of very geometrically dense cloth (which is not your case, btw). The trick consists in attaching each individual particle to its closest fixed particle directly. Not released yet, but 1.7 (in production) already has them.

Anyway i think your problem might have to do with the boat / sail mass ratio, as i´ve simulated a wind-driven, physically simulated boat (complete with buoyancy) for one of the new test scenes and had no stretching problems at all, without tether constraints:



I assume your sail simulation is merely aesthetic (you don´t actually need them to carry the mass of the ship around, as you are programatically moving the ship, right?), so there should be no stretching issues at all. If you want, send me a stripped-down version of your scene (just the ship will do) and i´ll set it up for you.

(Tip: your sail geometry is actually not very good for cloth simulation. Neither is mine, but... you should flip inner edges so they look like the following image. This minimizes biasing, which can introduce unwanted wrinkles in your sails caused by all constraints pulling in the same direction.)

 

theANMATOR2b,

Yes, it has slowly turned into a complete replacement for the built-in cloth. It can do everything it does and more! .
I´ve never used PlayMaker, and haven´t tried mixing ObiCloth with it, but there should be no problem afaik. Anyhow, check your inbox.

 

Just wanted to throw my two cents in that this looks great and is generously priced at $30. I don't know when, but I'll be picking this up for sure.

 

@arkano22,

This looks great! I'm curious, is this using PhysX for the cloth simulation? How does yours compare to Unity 5's (whatever version of PhysX they're using) in terms of performance?

 

Hi Adamz,

No, this is written in C# from scratch. I haven't compared it to PhysX in benchmarks, but when PhysX is in CPU mode (GPU mode is not a fair comparison ) i'd say Obi is about 25% slower. This is a quick-and dirty estimation, and i´m still doing everything in unity's main thread so there's quite some room for improvement.

However Obi gives much, much more control in terms of what is happening under the hood, so you can squeeze every drop of performance from it. And, it does the full thing (if you want it to), complete with two-way interaction, so no hard-wired shortcuts there.

 

Hi all,

I have good / bad news. Good news is that i´m rewriting Obi's core in plain C, and the preliminar tests show that the single threaded C version is much, much faster than its multithreaded C# counterpart. Bad news is that if i go this route, backwards compatibility with previous Obi versions will be lost, because serialized data from previous versions won't be compatible with the new input format. Which means that any cloth set ups you had already made, will have to be re-done (re-create ObiCloth component and set it up again.)

I'd like to know how critical backwards compatibility is for you, and how many performance problems you've had using Obi until now. For this purpose i´ve added a poll to this thread.

 

Any idea how much faster the C version is? Like ... twice as fast?

I'm thinking that if it is a very large improvement, users may not mind re-doing their work. But if it is only like 5-10% - which is nice, but not great - they might be less enthused about re-doing their work.

 

In the test scene, which consists of 9 32x32 particle planes, it is about x8 faster (I know this sounds far-fetched, but it's what the numbers say). Note it's not just the language which is different, also the implementation: i´ve switched from an AoS paradigm to SoA (struct of arrays), which is what both Shuriken and Nvidia Flex use, and that's the main reason for the incompatibility: the way data is stored in memory.

I personally think it's worth any incompatibilities but if enough people see it as a showstopper, I might consider keeping it as a separate product, and maintaining both versions. Also, the core source won't be freely accesible like it is in the C# version, so maybe this two-different-products approach makes sense. I'm just not sure about it.

 

I´ve also rewritten in C some other parts of the solver (nearest-neighbour search) and the speedup is now 12.5 instead of 8. I expect even more improvements once I rewrite normal and tangent calculations, since now they're done in C#, and they take up as much time as the constraint solver itself. You can see it here:

 

Hi arkano22,

Is the current version good for character clothing or just things like capes and tablecloths? Same question for the new version you're working on. Thanks.

 

I'm not presently using Obi Cloth, but a big concern of mine has been performance. This improvement sounds very promising!

 

I am more than happy with the re-write and associated incompatibility issues if you get that much of a performance improvement. That would mean a huge performance advantage over Unity 5's Cloth implementation then, correct?

 

Yes animate_xyz, it is also good for character clothing, hair, and things like flabby ears / antennas, muscles, and stuff like that. Plus you can make it all collide with its surroundings, and make other non-kinematic rigid bodies react to it.

 

Once I benchmark Unity vs Obi i will know for sure, but its quite probable that the C version of Obi will outperform it.

 

I suggest you go ahead with the C implementation. Performance is very important when it comes to cloth and it is better to bite the bullet now than when your community grows and transition becomes difficult.

 

Thank you. Will the new C version work in the same manner as the current C# version? If so then I don't think it's that big of a deal for people to update their current implementations.

 

Yes, it will work in a similar way. All editor tools will work exactly the same, but i´m considering a slight structural change: Instead of having separate solver options for each cloth object like we do now, I´m considering merging ObiWorld and ObiCloth components in a single "ObiSolver", which governs several cloth objects at once. This would allow for cloth inter-collisions (collisions between separate cloth objects) at no extra cost whatsoever as they are technically self-collisions, and allow me to introduce new kinds of constraints (fluids, smoke) under the same unified framework, a la Flex.

 

I've started working with Obi today and so far I haven't been able to get things to work properly. I imported a dress model that is rigged to a skeleton from Maya. No character just a rigged dress. For whatever reason I can't get my animation to play unless I set the rig to Legacy mode. (Am I missing something here to get it work in generic or humanoid?) So I'm going with what is working for now which is the legacy mode. I set up an obi cloth script with the exact same settings in the skinned cloth scene with the running character. I've fixed the upper half of the dress vertices and unfixed the bottom half. when I hit play in the Obi Cloth tool I can see some of the unfixed (blue) verts barely moving. Kind of like looking at twinkling stars in the sky. When I hit the Unity play button my animation plays but there are not cloth physics. Just the skinned mesh movement. I'm not really sure where to go from here. Any ideas anyone?


Update:
I finally figured out how to get my animation to play in the generic animation type in the rig tab just like it is in the sample player scene with the running character. I needed to drag the animation clip onto my model in the scene view. But still no cloth physics. I noticed that in the skinned cloth scene their is a separate fbx just for the animations. Is this something I will need to get this to work. If so How do I go about exporting a separate fbx just for the animation sequence?

 

Hi animate_xyz,

There should be no problem at all with generic or humanoid rigs, in fact the SkinnedCloth demo scene uses the "Generic" rig mode.
If your Skin Constraints Group is enabled in the ObiCloth component inspector, you wanna make sure you´ve painted some skin radius values so that the particles have a bit of room to move around. This is the same concept used by Unity's built-in cloth.

Steps:
- Select the skinned cloth.
- In the editor tools (grayish menu in the bottom-right part of the scene view) select "Paint" mode.
- Set the combobox right under it to "SKIN_RADIUS".
- Set the min and max values to something like 1 or 2.
- Paint over all your particles. They should turn orangish while painting. The brighter their color, the more freedom to move they have.

Now the simulation should run fine. There's no need to have a separate fbx for each animation, this is just good practice as it keeps your skin/skeleton data and your animations apart, but it should work fine with a single .fbx file.

If you really want to have separate .fbx for animations (which again, is not Obi's requirement, just something supported by Unity), in Maya's fbx exporter you can select which data to export. Untick all the stuff under the "Geometry" dropdown and tick the "Animation" checkbox. This will only export your animation data. If you have all your animations in the same timeline, one after another, you should really chop them up in different files as it is much easier to work with.

cheers!

 

Oh man, so sorry for taking up your time like that. I didn't notice the second video in the asset store that explains some of this. I did get it working. I really appreciate your help. I really love the plugin too. So much better than Unity's native tool.
Thanks

 

There seems to be a bug with the selections. Any time I paint or marquee select the vertices it is selecting the opposite side of the mesh. I don't have backfaces toggled on. The front image is the direction I have the mesh facing when I make a selection.

 

Yes animate_xyz, there was a bug indeed. It only affected skinned meshes with a root bone orientation unaligned with the world axes. I´m attaching a patched ObiClothEditor.cs with this bug resolved. You should replace /Obi/Editor/ObiClothEditor.cs with this one.

thank you for spotting it!

 

Now its time for someone to bring back Beast

 

No problem. Thank you for the quick update.

 

Hey arkano22, I've been able to get everything to simulate but I am running into performance issues as well as some collider issues. My skinned mesh (dress) has 3,379 verts simulating about 2,000 of those. Is this way too many to run a smooth simulation or am I doing something wrong. I've looked at the cpu performance during simulation and it's only hitting about 15% to 20%. The collider issue I've been having is that one of the capsule colliders keeps protruding through the mesh at the very start of the simulation. I've tried playing around with the collider settings for several hours and can't improve the result. I've also tried using a humonoid character with an obj version of the dress. I was trying to use the distance field collider but am getting an error saying that the geometry is non manifold. However, when I check the geometry in maya for non manifold geometry there doesn't appear to be any. The only thing I can think it might be seeing as non manifold are things like the eyeballs and eyelashes that are pushed in the character. But this is pretty standard practice for any character so it shouldn't be an issue.

I should probably give you a rundown on what it is I'm trying to achieve so that you may better guide me as to the proper workflow for such a thing. I am applying clothing to a user via the kinect video feed to which the user has control of through their skeletal tracker. This works no problem with skinned meshes but doesn't look very natural. So the next step is cloth physics but obviously this needs to run smoothly which I have not been able to get even without the kinect in a standard project. Currently the best I've been able to get is 15fps. That was with no colliders and everything except the stretch constraints turned off.

Thanks and sorry if I've been a bit of a pain in the butt.

 

Hi animate_xyz,

Don't worry, cloth simulation for games is not exactly a light topic and it is easy to head in the wrong direction.

First of all, if you're doing character clothing forget about distance colliders, as they only work for static (and closed) geometry. Distance fields work by pre-calculating distances to a surface from every point in space. So if the surface changes shape, all pre-calculated distances must be re-calculated effectively rendering the distance field useless. Direct deformable mesh vs deformable mesh collision (such as skinned character vs cloth) is prohibitively expensive, more so when using continuous collision detection, so it is very rarely used for realtime stuff and Obi does not support it. The usual workaround for character vs cloth collision its to use non-deforming colliders, such as capsules, attached to character bones.

Second, directly modeling a dress and having the simulation rely on accurate collisions around the shoulders, waist, etc is a recipe for:

a) tunneling issues
b) over-stretching
c) low performance

a) Fast moving colliders such as a waving arm pose a challenge for the collision detection pipeline, when using high time steps (which are pretty common in games). Most of the time the cloth just misses the collider movement and the arm/leg/whatever sticks out of the cloth. Of course you can get around tunneling by just iterating more times or lowering the physics timestep. But more iterations = lower performance.

b) Suppose cloth vertices near the shoulders do accurately detect all collisions with no tunneling, and so the rest of your cloth vertices are "hanging" from the character's shoulders. The more stretch constraints are between any vertex and the nearest colliding or fixed vertex, the more problematic is for stretch constraints to keep the cloth edges from stretching. Tether constraints can reduce this to an extent, but will only work for fixed particles, not colliding ones. The only real solution here is to either increase the number of iterations for stretch constraints (which will negatively affect performance) or reduce the number of stretch constraints, that is, your cloth poly count.

c) Solutions for both a) and b) are performance hungry, and so c) becomes the third problem.

So, how is character clothing usually done in games? There are two main methods, both involve "cheating" to a certain degree:

Method 1) Proxy meshes

Have a very high poly clothing piece, with pockets, several layers of cloth, or non-despreciable thickness? Create a low-resolution version of it, with no thickness whatsoever. Then, for each vertex of the low-poly version, create a bone for your hi-poly and skin it to them. Then, simulate the low-poly cloth and after each simulation step, move the bones to the corresponding vertex position/orientation. This way, you have effectively skinned the high-poly mesh to a low-poly simulation, getting rid of b) over-stretching and c) low performance. If a) is a problem, you can spend a few extra ms in collision detection.

This method was used in Alan Wake, for instance. There's a very complete article here:
http://www.gamasutra.com/view/feature/4383/the_secrets_of_cloth_simulation_in_.php?print=1

Method 2) Skin constraints

Skin your cloth (dress, jacket, pants, whatever) to the same skeleton used for your character. Then, apply skin constraints to it. These will loosely link the cloth vertices to their skinned position, so that no matter what kind of movements your character performs, the cloth will always be able to return to a reference configuration. This solves both the stretching and the tunneling issues, and is very performant. This method is used by Unity's default cloth, Nvidia's Apex, and Obi. In Obi you can see it in action in the SkinnedCloth demo scene.

For your case, i'd reccomend to use the second method. Cloth is a very expensive thing to simulate in general, and not always intuitive to set up. Hope this small guide helps you (and others) in some way!

 

This has been a huge help. I've got everything working now. My fps are still on the slow side but not as bad as before. I have to imagine this is due to my vert count as well as fine tuning some settings. Thanks.

 

Hi, arkano22
Could you make a video tutorial(demo on youtube) how to animate skirt/dress using your asset?

 

Yes... A tutorial on how to animate skirt, dress, hair etc. with fuse characters would help me decide if I should buy your asset.

 

And I will do one . However i´m pretty busy right now doing a major rewrite of the whole system, so it will have to wait a little bit. In a couple of weeks I hope to have great news to share with you all!

 

Hey arkano22, I'm trying to get capsule colliders to work with a dress and set up everything based on your YouTube tutorials. However the colliders don't seem to be working at all.

In one of your earlier posts you mention that there could be a tunneling effect with fast moving colliders and to iterate more times or lower the physics timestep. So I bumped up the iterations on the collision constraints group to 10. Still no affect on the colliders or the performance. Couldn't quite figure out what you meant by physics timestep? Also tried adding the ObiWorld component to the MainCamera and as a separate GameObject. No change.

I've attached screenshots of all my settings to ObiCloth and ObiWorld. As you can see the colliders on the lower legs seem to be poking straight through the dress. Really appreciate any input you can provide on this.

 

Hi Dlu,

Just to rule out possible causes: If you select the object that contains the ObiWorld component, you should see faint blue boxes around the colliders and the cloth, indicating that they are in fact correctly added to the ObiWorld. If you can´t see them, send me the scene and I´ll try to find the cause. Another user had a similar problem and it turned out some other plugin had created invisible components in their colliding objects that prevented them from being considered for collisions.

Btw, the physics timestep (which I think is not the issue here, but still) is a pretty critical part of anything having to do with physics in Unity. It is located in Edit->Project Settings->Time->Fixed Timestep, expressed in seconds. This is how often the whole physics simulation is updated, not only for cloth, but for all the other things. High values will mean coarser and faster simulation. Low values, slower and more accurate. Playing with different values often results in performance or stability improvements.

cheers!

 

Hi guys!

It's been a while since the last time I got out of my programming cave so I thought I would keep you updated on what's going on. As you know, I´ve been rewritting Obi in C++ due to popular demand of better performance, and so far so good. But during this process it has grown into much more than just a cloth simulator.

Since cloth is simulated using particles and the solver is now a lot faster, it has been very easy to use the same particle based framework for other kind of simulations. Apart from simulating cloth, soft bodies and rigid bodies (things it has always been able to do, to an extent) Obi can now simulate granular materials and fluids, and I plan to extend it to smoke and maybe plastic/deformable rigids. All of these seamlessly interact with each other since at the end of the day, they`re just particles:

The architecture has changed quite a lot, too. Cloth has been split into several components, but things just make more sense.

The thing is, 30$ is a pretty low price for such a time consuming and complex system not unlike Lagoa, Nucleus or Flex. But I don´t want to force people to purchase an expensive system if they're going to use only one aspect of it (cloth, fluids, smoke, etc). So I think I´ll keep it a modular asset, so that you guys can purchase each module separately, but still have seamless interaction between them if you own multiple modules.

That way, cloth stays 30$ as always, and if you later need fluids, you can purchase them for <insert price here > and have cloth and fluids interacting with each other. The whole system (cloth + fluids + smoke + rigid/deformable/soft bodies) shouldn't exceed 100$ in price.

Thoughts about this?

cheers!

(PD: The spherical particles you can see in the video are not real spheres, they`re impostors -billboards with depth and normals- so that there can be thousands of them on screen at once with almost no performance hit.)

 

Hi,
I have bought obi and I'm happy with it,
stunning with the new performance and I want ask you if can provide a example with waterfall and fountain also in footage...

Cheers!

 

I like the modular approach to features and pricing, @arkano22. It makes sense to me. I would suggest considering upgrade paths in the asset store so that customers can buy multiple assets from you at some sort of discount (up to your judgment). That might encourage more folks to buy the whole lot

 

The direction Obi is headed looks very interesting, but also like it might be a big bite to take.

I look forward to seeing what you are able to do with it.

One of the chronic problems with water is that simulations normally are very limited in scope. You can get ocean water, but not swimming pool water (or vice versa), or you can get a flat plane but not a gently descending river or stream.

It would be nice to have a system that efficiently handles fluid motion, with impacts and interference, but I don't know how you would blend it into something like Ceto, to get more fully functioning real world water. It always seems like we end up with a lot of specialized water solutions that don't play well with one another.

 

Hi Hopeful!

Thank you for your words .

The thing with water and other fluids is that irl they exhibit very different behavior depending on the scale and environment. Thus it is just not practical to use the same method to simulate all fluids in a game. At the core all fluid behavior emerges from the same set of equations, though. A similar thing happens with lighting: ambient light, specular light, reflections, refractions, ambient occlusion...they're all byproducts of the same basic equations, but in realtime you have to cut corners and use different methods for different situations. That's why things like spherical harmonics, ssao, cube map reflections, lightmaps...etc exist.

For offline stuff (movies) you can just use sph/flip for all fluids and raytracing for all the lighting, and it's fine if you wait for two days for a single frame to be rendered.

So, even if Obi manages to simulate a decent amount of fluid particles (cool for splashes, particle effects, etc), it is highly unlikely we will ever see a truly unified solution for fluids in realtime. Even if you could simulate the ocean using particles, you'd always want to use a more efficient, specialized solution for that.

 

But it looks like a ball pit

Is there a way to make it look like actual fluid?

 

Hi Zeblote!

Yes of course, this is rendered using raw particles . A water shader must be used along with it to look like real water.

The first part of the video is simulated using fluid equations. The second part with the orange and purple spheres, they use regular rigid body equations so they are supposed to look like a ball pit . This is used to simulate granular materials like sand, which in fact is just a zillion of small rigidbodies.