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

Warning: slightly technical post ahead.

Since people seem quite interested in inextensible ropes (ropes that can withstand high tension without stretching), I took one of the papers in my pile of stuff and implemented it. The paper in question is this one. In Obi, it has the name RopeConstraints.

Comparing the new RopeConstraints (left) with DistanceConstraints (right):

This uses a clever trick that allows to solve linear equation systems that are tridiagonal in matrix form in just O(n) (2n, to be exact: one sweep forward over all equations, and one sweep backward). It considers the entire rope as a whole, instead of a lot of small mass lumps joined by independently solved springs. It completely converges in just a couple iterations. Which means the rope doesn´t stretch anymore under high tensions, and it can be composed of as many particles as needed. Also, it doesn´t suffer from any numerical dissipation of energy, which results in a more lively simulation. And unlike other no-stretch algorithms like DFTL (dynamic follow the leader), it doesn´t impose any conditions on which particles can be fixed. All in all, it is a relatively obscure but great method for ropes, in my opinion.

The only compromise is lower stability compared to the more traditional distance constraints based approach. It doesn´t act so nicely when the system has no solution: imagine an inelastic rope with both ends fixed at a distance between them greater than the length of the rope: the rope would tear apart in the real world, as there's no way it can stretch. This tridiagonal matrix approach will not find a suitable solution to the system, and the rope will jitter between different configurations never coming to rest. Distance constraints on the other hand, react to this by returning a "close enough" solution: stretching the rope beyond its physical limits (which for some uses, looks much nicer).

Increasing the amount of RopeConstraint iterations boosts their stability, instead of their convergence speed.

So I will keep both systems. If you need a "don´t explode no matter what" rope, use DistanceConstraints. If you need a "don´t stretch no matter what" rope, use RopeConstraints. Tomorrow I will upload this ObiRope update (along with MeshColliders, and initial support for 2D colliders: box, circle and edges).

 

Appreciate the explanation. Glad you decided to keep both systems too, often times you need ropes that "Don't explode no matter what". Actually that's what drew me to this asset in the first place, as ropes that use rigidbody joints don't have hardly any leeway for stretching before they explode.

Is extensible rope via code supported (or planned to be)?

Anyway definitely on my buy list.

 

Obi's ropes use position-based dynamics, which is guaranteed to be stable no matter what (unless you explicitly add a source of numerical instability, as the optional tridiagonal solving algorithm I added). So regular distance constraints will work fine and will never explode or jitter. However they will stretch, and how much depends on how many iterations you spend enforcing them (which is an adjustable parameter).

Lengthening or shortening ropes via code is not supported yet, but I´m working on it. Right now ropes are instantiated from a spline, and will keep their length fixed throughout their lifetime.

 

Hi guys,

Both ObiCloth and ObiRope have been updated (still undergoing asset store's review). This update adds 2D mode support and basic 2D colliders: box, circle, and edge (polygons not supported yet). Mesh collider support has been added for ropes. Some collision bugs with box colliders have been fixed, and a sleep threshold has been added to prevent particles from jittering when over constrained. Rope constraints (renamed to Chain constraints) have been added for rope, and now it is possible to render actual chains made of custom link objects instead of procedural rope meshes.

Also, all constraint components are now automatically removed from the object when you remove the ObiCloth or ObiRope component in the editor. So no more manually removing a bazillion components after deleting a cloth or rope.

Anyway, check the asset changelog for an exhaustive list of changes. Phew!

The docs have been updated too to include a rope-specific section. A rope use-case has been added, which will show you how to make dynamic cables for a robot. (everybody loves robots!). Here it is:

Robot arm

Edit: I´ve also updated the collisions page of the manual, with new info on collision materials and settings, along with some insights on how is collision resolution implemented in Obi:

Collisions

Now it is time for me to prepare for my journey. See you in a month! I will regularly check the support inbox so feel free to write any questions you might have, I´ll do my best to answer quickly.

cheers,

 

Hi Yang!

To make separate cloth objects collide with each other:

- Make sure particle collisions are enabled in the ObiSolver.
- Put each cloth object in a different layer.

That's all. If you also want the cloth objects to be able to collide with themselves, turn on "self collisions" in the Obi Cloth inspector.

In case you're wondering, the same applies for ropes (if you own ObiRope).

cheers,

 

Hi @arkano22,
Great work!
Do you have any plans on adding chains in the ObiRope?
EDIT: I have read the previous message and understood that yes . But as I understand it is possible to create the chain with manually modeled 3d-model now.
So maybe any plans for procedurally generated chains ?
Thanks!

 

Hi Erich,

Yes, the next update can generate chains using modeled links. You can provide several different links and they will be used to automatically build the chain, either selecting one of them at random or using them sequentially.

100% procedural chains are not in the roadmap right now, but if people deem it useful I will add it.

 

Do we have to use the Obi shader for cloth simulation, or can we still use Obi Cloth with our own shaders?

 

Hi Deckard,

You can use any shader you want, it does not affect the simulation at all. There's a standard double sided shader included, since double sided cloth is a pretty common use case.

 

Hey Arkano! Does this also work if I have a double sided mesh (i.e. two planes siting on top of each other, vertices perfectly aligned but the normals facing in the positing direction each)?

 

Hi，Can you help me？How to control the number of the rope(or rope path)？Sometimes，it have so much particles，and overstretch。Thanks！

 

Hi Nipoco!

No, it won't work that way with any cloth simulator (not in a reliable way at least). Since there are no edges joining the corresponding vertices from the two sides of the cloth, so your mesh will be interpreted as two disjoint sheets.

Anyway you should generally steer clear of this technique if possible as it only adds innecessary geometry = overhead.

 

Hi,

You can lower the "resolution" parameter, then re-initialize the rope.

The default resolution (100%) creates enough particles to ensure there are no gaps in the rope and that there is a half-particle overlap, useful for collisions. However for long ropes it can result in stretching, if you dont use tether or chain constraints.

 

Thanks Arkano.
I just wondering how you can make something, for example, like a flag with different logos on each side. The double sided shader won't help in that case.

Anyway, definitely a nice looking plug-in. I'm sure I'll pick it up soon.

 

@arkano22 Thought so, thanks. Also, have you made progress with obi fluids?

 

Hi Nipoco,

You can just use a front-faces material and a back-faces material for the same object, which is in fact the method used in all Obi sample scenes (front faces use a blue texture and back faces a red texture).

Edit, longer explanation: In Unity you can use more than 1 material for the same object, the object will be rendered once with each material. If you use a front-faces only material and a back-faces only material, you´ll get a double sided object with different materials for each side.

cheers,

 

Hi Deckard,

No worries! ObiFluids is almost finished. Everything works nice and supports both 2D and 3D mode. I will publish it in about a month (I´m travelling to my home country right now and I barely can connect to the internet most days).

 

Hey thanks for the explanation. Seems I just learned something new

 

Hmph... All of my assets have double faces, because I started the project in other software(s). I have thought that my PC is too low for it, and I used pre-rendering (uRecord).

So, I have to redo all clothes and hair, to use not just your, but any cloth simulator? But with skinned mesh proxies, I don't have to do the details again... do I? Well, I think I'll wait xdd

 

Just bought the asset and really liking it (all demo scenes work fine)
but I cant get the unity chan tutorial to work... :|

edit: it works now BUUUUUTTTT:

if you select the skirt and then click play the skinned mesh render gets deleted from the object
(had it selected for like an hour and if you add it bac manually sometimes it completely F***es up the scene)


waiting for your fluid asset

 

Hi, new Obi user here….

Is there a way to smooth out the shadows? or smooth the polys? I need a big dramatic waving flag that fills the screen…. Am I better off increasing the poly count of my flag mesh? Or are there some other tricks to reduce the grid?

 

You can also drive a bigger mesh with a lower rez clothes?

I feel so patriotic just looking at that image and I'm not even american lol Thanks hollywood!

 

LOL!

Well, I hid the grid shadows as best I could…. Good enough for this weekend.

 

Just watched independence day: resurgence. This is so appropiate

It seems your shader is applying diffuse lighting per-vertex. Try using a per-pixel shader.

I vaguely remember that the Standard shader does per-vertex when no normal map is provided and per-pixel otherwise. You could try adding a flat normal map.

 

Hi VargaPD! I missed your post, sorry about that.

If your mesh is not skinned, you can use cloth proxies indeed. This will however be quite slow compared to the "proper way", which is to use materials. You will not only send twice the amount of data to the GPU, but you will also have the proxy overhead (binding the double sided mesh to the simulated, single-sided mesh). Also note that your simulation must be performed on a single-sided mesh, even if you later use it to drive a double sided one.

All in all, avoid double sided geometry for simulation. It just doesn't represent meaningful geometry, and in the worst case will not simulate at all.

Edit: this applies to all cloth simulators that i know of.

 

Sorry I haven't replied this long. So, yes, I think the best thing I could do to modify at least the clothes and hairs.

 

Hi!

Would this plugin work to fit a robber mask onto a head? I need the mask to respond/behave as cloth when the character is speaking(using blend shapes). A mask similar to this:
http://www.daz3d.com/ski-mask-for-m4

Thanks!

 

For this particular example, you would be _much_ better off transferring blendshapes into the mask…. Potentially even creating a completely different figure/head that is just the ski mask with all the unseen head polygons removed.

 

+1000 to this.

 

@arkano22 – Any updates on Obi Fluids? Do you have any idea when this may come out? You said about a month ago that it would be published in "about a month" are you still on track for this time frame? Finally, do you if it will work with VR? Thanks!

 

Hi macdude!

I just returned to Spain from my one-month trip yesterday (actually the plan was to return tomorrow, but some family issues forced me to take a flight earlier than expected). I´m still organizing things around, and will start working right away.

My short term roadmap is:
- Add android support to the Obi plugin.
- Prepare ObiFluids for release.
- Update ObiCloth, ObiRope, and release ObiFluids.

There should be no problem at all when using any Obi plugin with VR.

cheers!

 

A bit offtopic, but I recently saw a "vine creator/ivy generator" thing for Unreal…. Seeing it in action made me think of Obi Rope (the scene where you made the rope "sticky" and it clung to other objects….. I'm just throwing it out there for possibilities either as an expansion for Rope or potentially another product that uses your particle/collision system….

This was the product (I realize it is not the same thing, but as I said, it's a suggestion, hopefully inspiration)

 

Really nice! that would be a great addition to ObiRope splines indeed. I plan to make spline manipulation more flexible in the future so having such powerful procedural generation would be great. Thanks for pointing this out!

 

Awesome, looking forward to it! Do you have any time frame on its release date? A few days or a few weeks?

And I realize I've never heard about mobile performance with your plugins – will Obi fluids work alright on mobile or is it best used on Desktop only?

Also, is the particle simulation separate from the particle rendering? Would it be possible to simulate a fluid on a server and then only render them on a different device? Thanks again for your answers!

 

Hi macdude,

I´d say about a week till it begins the Asset Store review process. Usually it takes another week for them to approve it, so two weeks total until it reaches the store.

Mobile performance is of course worse in general, but it all depends on the amount of particles and constraints you have. Fluids are on the expensive side, mainly because of the sheer amount of particles needed to fill a given volume with enough resolution. 2D fluids are cheaper than 3D fluids, for the same reason.

Performance also depends on a very fluid-specific parameter: the smoothing radius. Larger radii cause fluid constraints to consider more neighbor particles for each particle, which gives a smoother, more fluid-like result but quickly degrades performance. Low radii cause the fluid to look just like individual particles colliding with each other. A radius of 1.5 times the rest radius usually hits the sweet spot.

In my experiments, anything around 1000 - 1500 fluid particles is good enough for 2D mobile fluids. 3000 particles are usually ok for 3D desktop fluids.

Particle rendering is completely decoupled from simulation, as the simulation only outputs particle data (positions, velocities, densities, etc). Obi uses a screen-space approach for it, you need to add a special renderer component to each camera that needs to render the fluid. Of course you could roll your own rendering method if you wanted to, using a different method (marching cubes, perspective splatting, whatever).

To simulate on a server and render on a different device, you'd need to send particle data to the client which can be a little heavy (bare minimum are particle positions, supposing 1000 particles that's 12kb of data per frame). I´d look into reducing precision (using halfs instead of floats) and some form of additional compression.

cheers!

 

Regarding extending the rope, I have found that by changing Stretching Stiffness in Inspector it is easy to give the impression of extension. However, when I do it in code nothing happens. Any ideas? Or should I just wait until t you add a proper extension functionality?

 

You need to push the constraint data to the solver by calling:

Code (CSharp):

1. distanceConstraints.PushDataToSolver(new ObiSolverData(ObiSolverData.DistanceConstraintsData.DISTANCE_REST_LENGHTS));

after modifying the distance constraint lengths, just like the editor scripts do.

This is a valid way to change the rope length, but new particles will not be generated--> rope resolution will degrade--> collisions will be missed. The "better" way to change rope length (and what I´m implementing) is to dynamically generate new particles so that the inter particle distance remains the same, and the rope resolution stays constant.

 

Thanks for that - when do you expect to have the length change available?

great work by the way!

 

What is the method of collision detection?BVHs or spatial hashing? And so as self-colision?

 

Hi Redrag!

The next ObiRope update should be available in less than a month, and it will include proper rope length change.

 

Hi Yang,

Hierarchical spatial hashing for both collisions and self-collisions. The grid gets rebuilt every timestep and amortized for all constraint relaxation iterations.

In the case of mesh colliders, a hierarchical grid containing whole triangles is generated in local space just once, and then particle positions are transformed to the collider's local space and tested against the grid. No need to rebuild it unless the collider geometry changes.

 

Whats the performance like of obi cloth on mobile?

 

Hi kriket,

Currently only iOS is supported, although Android support has been completed and will be available very soon.

Performance depends on lots of things: which cpu does your device have? how many particles (vertices) does your cloth have? how many constraints? how detailed a simulation you need?

In general, cloth is pretty expensive in mobile unless you use simple cloth models with relatively few constraints. Also It's not the same to use cloth for eye-candy or as part of your game mechanics. If you just want to add some eye-candy like a flag that does not affect gameplay, I'd say the performance hit is usually not worth it, as you can accomplish the same or very similar effects using cheaper techniques: baking, texture effects, etc.

Obi is extremely customizable (as others can tell you, it has heaps of parameters and is highly modular) so you can get extremely high-detailed (slow) simulations or very simplistic and fast ones. It's a 100% multithreaded CPU implementation, makes no use of the GPU.

If you're unsure if it will meet your needs, I'd say try it. If for whatever reason you don´t like it, just request a refund, no questions asked .

 

I will have to take u up on that offer since I need cloth for actual gameplay mechanics. But the whole art-style is low-poly and the game wouldnt have just one rigged-character. Cloth itself would be low-poly as well. So I think it might actually run fine. I just tried unity cloth on my 3 year old android, moto g 1st gen and unity cloth works just fine (there were two with about a couple hundred vertices each and two fully rigged characters). But I am looking for collisions which unity cloth cant do but obi cloth can (from what i could tell from the vids on your youtube)

But android is a must so can i ask, when is android support getting released? This month? Next?

Thanks.

 

I´m uploading an update with Android support tomorrow, and Asset Store validation usually takes about a week. So yes, it will be available way before the end of August.

Two-way interactions with rigid bodies is fully supported, as is collision with all collider types. What you describe should be no problem in terms of performance.

cheers!

 

Hi there,
I'm very interested in this asset, but i have a few questions regarding options in this cloth asset.
For the soft body aspect is it possible to simulate metal like objects? So the object deforms and bends but remains in that shape for example something like in BeamNG cars?

Aerodynamics - is it possible to build an airplane or something that will lift and achieve vector flight?

Thank you!

 

Hi sashahush,

No, soft bodies are modeled as air-filled balloons. So they cannot be completely rigid.

It is certainly possible to model an aircraft using cloth. I´ve modeled wind-propelled boats, which follow a similar principle (except using drag instead of lift). However the wings will have to be made out of cloth or a similarly soft material.

In the future, ObiSoftbodies will use shape-matching constraints to allow for the whole range of soft body behavior (from completely rigid to elastic / plastic). No release date for this asset yet.

cheers!

 

Hi arkano,

Great asset so far from what I've seen, however I am having some problems with it;
While creating 'ObiMeshTopology', after selecting a mesh and hitting 'generate', unity crashes. What's more is the crashes are inconsistent so it's making it hard to figure out what could be wrong with the meshes. Are there any limitations to the meshes that can be used as a cloth? To explain further take a look at the image I have included.

I have 8 low poly meshes I am trying to turn into cloths.
Mesh 2 and 8 have always worked fine and had no problems, they were created from planes which were cut in half and then I deleted the face I didn't need, then divisions added.
Mesh 1 and 5 have never worked. Tried creating them using planes and moving the vertexes and also tried using 'Create Polygon'
Mesh 3, 6, and 7 worked once when I created them using the 'Create Polygon' tool. However after a crash and trying them a second time only 3 worked. 6 and 7 both caused crashes after that.
With the exception of 2 and 8 they are all the same. just slightly different sizes.

I have tried all the following to get the meshes to work:
Delete all by type > History
Mesh > Cleanup > (all options tried)
Freeze transformations / Reset transformations
Saving the files as FBX and OBJ

I am using Maya 2017 on OSX 10.11.5
Unity version is 5.3.5f1 personal

any help would be appreciated.

edit: I've tried just duplicating the meshes that work and just scale them to fit, I encounter a crash when I press play and test the scene.

 

Hi newmanski,

Obi cannot generate topologies from non-manifold meshes. It is designed to fail gracefully under these circumstances, but obviously it hasn´t been tested with all possible mesh inputs...double check in Maya whether your mesh is non-manifold.

Specially, triple check that you are not using double-sided meshes, as not only are they non-manifold, but if the vertex winding order is inconsistent they can cause all sorts of problems later on. Double-sided surfaces should be achieved using a shader (you can use the one included, which is used in all sample scenes).

If all else fails, would you be able to send the mesh to me so that I can track the problem down?

cheers!

 

They are definitely not non-manifold, they are just planes. And yes definitely single sided meshes, I have been using the shader you supplied in the asset.

I have fixed the problem simply by adding more divisions to the meshes, however I'm trying to keep them low-poly to keep a consistent style throughout my game. Is there a minimum verts/faces count for the topologies?