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

I tried it. Now it completely crashes Unity and exits.

 

Let me tell you how the original error happens in the pulley sample scene.
I just select the rope. Then hit play.
It gives me the error:
Can't remove MeshRenderer because ObiRope (Script) depends on it
UnityEngine.ObjectestroyImmediate(Object)
Obi.ObiRopeestroyRequiredComponents() (at Assets/Obi/Scripts/Actors/ObiRope.cs:266)
Obi.ObiParticleActorEditor:OnDestroy() (at Assets/Obi/Editor/ObiParticleActorEditor.cs:130)

 

This will get fixed in the next update. You can get rid of it by deleting line 266 in ObiRope (GameObject.DestroyImmediate(), but the error itself is innocuous. Will not actually make any difference in the editor or a standalone whether you fix it or not, so I didn´t release a hot fix for it.

 

If Unity crashes with DX9, I´d look into it as judging from your editor log, DX11 seems unable to create vertex buffers / render textures. Neither DX version is working correctly for you. Unity crashing in DX9 mode is not normal at all, so I suppose there's some config problem going on with your system.

 

This actually fixed all the issues (commenting out both line 266 and 267) Thanks! ;-)

 

I'm in the process of creating a dynamic rope drawing script (I hope that is possible, since at least there are steps to achieve this in editor). One of the first questions I have is how can I initialize the rope after I add a point in the curve. Right now I've tried the Rope.GeneratePhysicRepresentationForMesh() but its not doing anything.

 

Hi Dennik,

Keep in mind that GeneratePhysicRepresentationForMesh() is a coroutine, so you must use StartCoroutine() to call it. Calling it as regular function will do nothing at all.

Attached you´ll find an example script that generates a rope between two transforms at runtime. You can start from there and build anything you need.

 

Hello @arkano22 I am looking for a cloth system that lets you set which areas of a mesh are static and which can move and your system looks perfect, but my meshes are created at runtime and can be altered, is it possible to set which areas of the mesh (fabric) are static and which can be moved at runtime?

 

Hi Arcano22,

I am interested in the creating the particle handles in real time too.
Actually I amost finished the script. I have just one issue - I cannot get the particle "deformed" positions to calculate the nearest particle to my handler.
I use this code to get the array of th eparticle positions:

actor = GetComponent<ObiActor>();
Array.Resize(ref wsPositions, actor.positions.Length);
for (int i = 0; i < actor.positions.Length; i++)
{
if (actor.active)
wsPositions = actor.transform.TransformPoint(actor.positions);
}

Seems wsPositions contains particle positions before the cloth was deformed.
How to get the positions of "deformed" particles?

Thanks,
Dmitry.

 

Hi tapticc,

Yes, perfectly doable. You just need to fix the parties (vertices) you don't want to move by setting their inverse masses to zero (which is done by just setting values in an array)

cheers,

 

Hi Dmitry,

Use the solvers' renderablePositions array for this, index it using the actor's particleIndices array, like this.

// current position of the first particle in the cloth:
solver.renderablePositions[cloth.particleIndices[0]]

As you discovered, the actor's "positions" array are initial, undeformed positions, and do not get updated during the simulation. They are there for serialization purposes.

cheers!

 

Thanks

 

Thank you! It works great!

 

Hi, do have a rough timeframe for when the new version of Obi Cloth with improved performance and tearing will be released?

 

Hi Deckard,

I´m aiming for 4-6 weeks from now aprox, and developing like crazy. Rest assured it will be worth the wait .

cheers,

 

@arkano22 Hi there! I have my eyes on this asset for quite a while and so I would like to ask THE question: do you think Obi is production-ready? By that I mean:

- Works in a stable, reliable fashion
- Works on PC and consoles (Xbox One and PS4)
- You plan to keep providing support for it

If the answer is yes then I think I'll jump in...

And a bonus question for you: at the moment I'm using the default Unity cloth and the game objects that use it all go through a "crazy stretch" phase when getting from deactivated to activated: a small flag will stretch 30 meters before going back to its normal size over a couple of seconds. Does obi suffer from the same issue?

 

Hi Seith:

- Works in a stable, reliable fashion:
Yes, we´ve used it in production code (a soccer game goal nets and player clothing, in case you're wondering) and has worked wonders for us. We developed it out of necessity, then made it grow to cover more use cases and make it more user-friendly.

- Works on PC and consoles (Xbox One and PS4).
Nope. It works on PC and Mac, iOS and Android. No support for consoles yet, but it is on our roadmap.

- You plan to keep providing support for it.
Yes! And for a very long time if things go as planned, as I´m building a small company around it. If we ever stop supporting or developing it, all the library source code and internal documentation will immediately go open-source. The reason Obi is a c++ library (.dll) is performance, not obscurity. It only makes sense to make sure others can continue developing and modifying the source if we can no longer do it for whatever reason.

About the "crazy stretch" issue: I suppose you're deactivating the cloth component, moving somewhere else and reactivating it. That causes it to stretch a lot, as the vertices move from their old position to the new one. Is that correct? If so, you can prevent it by setting the world velocity scale and acceleration to zero before deactivating it, move the cloth, wait one frame and and reset the world velocity and acceleration values.

Obi does not suffer from this as simulation is already performed in world space, although it's hardly an issue: it's just the way cloth works.

cheers!

 

Excellent! Thank you very much for your detailed reply.

Unfortunately the only thing that's going to keep me from using this asset is the lack of support for Xbox One and PS4. It's a shame as I was really looking forward to ditching my makeshift system for a much more robust one. I'll keep on checking on the development of Obi because it really looks like a super nice asset you've got there! Maybe for Ghost of a Tale 2!

Regarding the default unity cloth bug I was mentioning, it's actually affecting non-moving objects (static flags on poles). And I meant to say the issue happens when the entire game object (on which the cloth component lives) is turned off then later on (seconds or even minutes) is activated again. So it doesn't involve enabling/disabling the cloth component nor moving the game object itself at all.

 

No worries! . I hope we can see Obi in your games in the future.

About the cloth issue you mentioned, I just tried to do it that way -deactivate the whole object, not just the cloth component, and reactivate it later- and it does this weird stretching. This seems like a bug indeed as one would expect the simulation to resume where it left when deactivated. If I were you I´d report it to the Unity devs so that they can fix it.

 

Thank you! I will!

 

About Obi Advanced Rope, does that rope affect by wind? I want to buy but I need a rope that react to the wind.

 

Hi Ksam,

No, not currently, sorry.

 

For some reason the particle editor window doesn't open for me.

link: https://www.dropbox.com/s/po7xizfzkkj9kd3/Screen Shot 2016-11-23 at 11.16.18.png
tested in Unity 5.4.2 and 5.4.3. Any ideas? (all editor resources and gizmos have been moved to the correct place)

 

Appears to be a problem with a Retina 5K iMac. This fixes the issue and shows the window correctly:

// Sceneview GUI:
Handles.BeginGUI();

GUI.skin = EditorGUIUtility.GetBuiltinSkin(EditorSkin.Scene);

if (Event.current.type == EventType.Repaint){
uirect = GUILayout.Window(0,uirect,DrawUIWindow,"Particle editor");
uirect.x = Screen.width / 2 - uirect.width - 10; //10 and 28 are magic values, since Screen size is not exactly right.
uirect.y = Screen.height / 2 - uirect.height - 28;
}

GUILayout.Window(0, uirect,DrawUIWindow,"Particle editor");

Handles.EndGUI();

 

Hi Robertsze,

Yes, this is a known issue that's been fixed for the next update. The "correct" fix is this:

if (Event.current.type == EventType.Repaint){
uirect = GUILayout.Window(0,uirect,DrawUIWindow,"Particleeditor");
uirect.x = Screen.width/EditorGUIUtility.pixelsPerPoint - uirect.width - 10;
uirect.y = Screen.height/EditorGUIUtility.pixelsPerPoint - uirect.height - 28;
}

using EditorGUIUtility.pixelsPerPoint instead of "2".

 

Thanks. Unfortunately we cannot use the obi cloth plugin because of performance reasons on low-end mobile devices (iPhone 4S, Samsung Galaxy S2/S3). We tried to "animated" a parachute with around 1500 vertices with collision enabled but this resulted in around 4 fps (from 60fps). Guess its just too much work for these devices. Although, we really loved to visual appearance of the cloth solver, looked amazing.

 

Hi Robert,

Yes, 1500 vertices with collisions enabled is way too much for mobile. You could try however to disable some constraints (bending, aerodynamics, etc) and lower the amount of iterations for all others, or wait for the next update (a couple weeks from now) which includes a performance improvement of about +250%.

cheers!

 

Hi @arkano22

Thank you for supporting this great asset. How is fixing interaction between Obi Rope and terrain collider going on? When should we expect this fix and is there any chance for extendable ropes coming soon? ^_^
By the way, is there a way to add forces to some of the rope particles? Some API method similar to Rigidbody.AddForce()?

 

Hi electric_jesus,

Next version of all Obi plugins will include a way to add external forces to particles, and basic force field components that use this functionality. The bug in Obi Rope collisions has been fixed (in fact it affected cloth and fluids too, in a subtle way) and will be available in the next update, together with extensible ropes.

The next update of Obi Rope will be released in about 5 weeks. Obi Cloth will be released first, then ObiFluids, and ObiRopes will be the last one.

I will make a proper announcement here in the forum when the next updates are available. cheers!

 

This is ultimately cool, man!

 

Hi!
I'm trying to devise a way to make a cloth grabbable/draggable. I've done this in the past with Unity 4's InteractiveCloth using attached colliders and with Unity 5's Cloth via a procedural bone system (pretty awful). From what I can tell, these are the steps I need to do to recreate this behavior with Obi:
1. Find the nearest cloth particles to a ray.
2. Add a pin constraint.

Regarding 1, I can't find an efficient way to do this - at least not one that is exposed by ObiCloth or ObiSolver. The closest I can get is to fire a really fast, invisible collider and attach to the solver.OnCollision event. This doesn't seem like a reliable solution, though. In the meantime, to test dragging. I manually created a pin constraint to a sphere collider and moved the collider around.

Regarding 2, I can't get the pin constraint to behave properly. Despite the offset being 0, in practice there is always a small offset, which increases as the collider moves further away. The cloth doesn't behave realistically either - the vertices near the constraint stretch disproportionately to the rest of the cloth, which barely stretch at all. I will note that 2 corner particles are fixed and a tether constraint has been generated.

My goal is to allow the cloth to be "plucked" off a laundry line, when it is sufficiently stretched.

Any suggestions? Thanks!

 

Hi daterre,

It would be much easier to use a handle, instead of pin constraints. Pin constraints are meant to be used only with rigidbodies, since they transfer energy from the cloth to the rigid body and viceversa, to achieve two-way coupling.

A handle however simply fixes particles in space, "deactivating" their simulation, and allowing you to move them around. They are simpler to use and much, much cheaper performance-wise.

To create a handle in the editor: enter particle edit mode, simply select the particle(s) you want to be able to drag and click "Create handle" in the particle editor menu. This will create a new object in the hierarchy under which the selected particles are grouped. You can then use this object to move/rotate/scale these particles at will.

Creating a handle at runtime is also possible, if slightly more involved. I can provide a sample script for you if you wish.

Edit: Regarding 1), it is way faster to do it in screen space, if you don´t need picking to be occluded by other objects in the scene. Just project particle positions to the screen and pick the one closest to the mouse position.

cheers!

 

Thanks @arkano22! I guess I missed the whole part about handles in the documentation. A script would be greatly appreciated And yes, I guess I could overcome occlusion with some simple checks and project to screen space. Thanks for the suggestion!

Another question: could any problems arise from duplicating a cloth object in the editor? I duplicated a perfectly good cloth object, changed the duplicate's mesh & topology asset, but when I hit play it goes crazy (wrong vertex count, vertices jumbling all over the place).

 

Awesome stuff man! Super realistic cloth system! Good job!

 

Hi Daterre,

Attached you´ll find a script that detects collision of particles against any collider in the collider group, and generates a handle our of the collider, so that particles stick to it. The important part is the AddParticles() method in the handle component. You need to pass the particle index, the particle position in world space, and its inverse mass (so that the mass can be properly re-set when the handle is destroyed).

There's a bug that prevents changing the topology in a duplicated object. It was detected a while ago and has been fixed for the next update. In fact, there's no need to change the mesh AND the topology in the next update, just the topology. The mesh is made to match the topology automatically.

 

Hmm, I guess you would need to pick the particle that's also closest to the camera for the case where the cloth is folded and occludes itself. Also for particles along the edge somehow ensure they are not picked if the picking position is off the edge of the cloth.

I've been adding a BoxCollider and a disabled MeshCollider to the ObiCloth, when the BoxCollider detects a hit I then disable it and enable MeshCollider and set meshCollider.sharedMesh = cloth.clothMesh and then raycast again using meshCollider.Raycast(), then use hit.triangleIndex to find the closest particle on the hit triangle. This can also hit cloth backfaces with the new Unity 5.5 Physics.queriesHitBackfaces flag. Not sure if this is the best approach.

 

Seems like a very clever approach. Not sure how fast it is to change the shared mesh of a mesh collider on the fly, but it cannot hurt if you only do this once when the user clicks and the ray hits the box.

 

Thanks for all the help. I tried @rectalogic's method, very minor impact on a single frame check (checking against the box collider first is a great idea - I keep the box collider bounds updated by using the cloth.clothMesh's center and size). Now I'm stuck on how to turn a triangle index into a particle, for use with the handle script your kindly provided. I can use the cloth.clothMesh to get the vertices of the triangle, but how to get a particle index from a vertex?

 

This is how I did it:

Code (CSharp):

1.  
2.     private int ClosestVertexIndex(RaycastHit hit) {
3.         Vector3[] vertices = meshCollider.sharedMesh.vertices;
4.         int[] triangles = meshCollider.sharedMesh.triangles;
5.         int index = hit.triangleIndex * 3;
6.         float d0 = Vector3.Distance(hit.point, vertices[triangles[index]]);
7.         float d1 = Vector3.Distance(hit.point, vertices[triangles[index + 1]]);
8.         float d2 = Vector3.Distance(hit.point, vertices[triangles[index + 2]]);
9.         if (d0 < d1) {
10.             if (d2 < d0)
11.                 index += 2;
12.         }
13.         else if (d1 < d2)
14.             index += 1;
15.         else
16.             index += 2;
17.         return triangles[index];
18.     }

 

Thanks! So that finds the nearest vertex to the hit point. But how do I turn the vertex into the "particle index" that ObiSolver uses? @arkano22's script gets 'pindex' from the collision event:

Code (csharp):

1. int actorParticleIndex = handle.Actor.particleIndices.BinarySearch(pindex);
2. handle.AddParticle(actorParticleIndex,wsPos,handle.Actor.invMasses[actorParticleIndex]);

I need to get it from the vertex index.

 

That index is the particle index, although if you have multiple cloths using the same solver it might not be.

 

Actually, there is a simpler way to get a particle index from the hit triangle index directly.

The ObiMeshTopology asset used to generate a particle representation of the mesh contains topological information about the mesh that is useful here. Note that particle indices != vertex indices in general, as some vertices in the mesh can share the same position yet have different normals/tangents/uvs. In this case, a single particle is generated for all vertices that share the same position, and you´d have less particles than vertices in the mesh. This is reflected in the topology -which only cares about adjacency and connectivity of the mesh, not about render data such as normals or uvs-

The topology class is based on the half-edge data structure. You can read more about it here:
http://www.flipcode.com/archives/The_Half-Edge_Data_Structure.shtml

Also, once a cloth instance is added to the solver, a mapping is performed between cloth particle indices (which range from 0 to number of particles) and solver particle indices (which are assigned depending on the current amount of allocated particles and how many cloth instances are already in the solver). You can use the cloth.particleIndices array which contains the actual solver particle index for each cloth particle.

With all this info under your belt (which is not trivial at all, I know, and not very well documented anywhere, my apologies), you can do this:

Code (CSharp):

1.  
2. // get all three edges surrounding the triangle hit by the ray:
3. int edge1 = cloth.topology.heFaces[hit.triangleIndex].halfEdge;
4. int edge2 = cloth.topology.heEdges[edge1].nextHalfEdge;
5. int edge3 = cloth.topology.heEdges[edge2].nextHalfEdge;
6.  
7. // get indices each one of the 3 particles in the triangle:
8. int p1 = cloth.topology.heEdges[edge1].endVertex;
9. int p2 = cloth.topology.heEdges[edge2].endVertex;
10. int p3 = cloth.topology.heEdges[edge3].endVertex;
11.  
12. // get current world-space positions of these particles:
13. Vector3 position1 = cloth.Solver.renderablePositions[cloth.particleIndices[p1]];
14. Vector3 position2 = cloth.Solver.renderablePositions[cloth.particleIndices[p2]];
15. Vector3 position3 = cloth.Solver.renderablePositions[cloth.particleIndices[p3]];
16.  
17. // use positions to determine which one is closer to the hit point,
18. // then use p1,p2 or p3 as the particleIndex for the handle.

 

For simpler meshes such as planes this holds true. However in the general case this is not entirely correct rectalogic, as for some meshes (such as Unity's default sphere mesh) you'd have less particles than vertices in the mesh. If you assume particle index count == mesh vertex count, you're in for out of bounds access errors.

The correct approach is to use the topology asset associated to the cloth to map from vertex index to particle index and viceversa.

 

Obi Cloth 3.0 is going to be released in about two weeks if all goes well, and I wanted to give you guys some info about it and how are things going for us.

I´ve started a small company dedicated almost entirely to the development of Obi. We're only two people as of now, but that already makes a huge difference to me as I can concentrate more on low-level programming stuff. As the result of a few months of hard work, Obi Cloth 3.0 will be released soon, followed by Obi Fluids and Obi Rope. The three of them are really big updates, focusing on performance and usability.

We´ve tried really hard to set the lowest possible price tag that allows us to keep developing Obi, while maintaining it affordable for small studios and hobbyists.

If you already own Obi Rope or Obi Fluids, you will be able to upgrade them at no cost. Also, the price tag for both assets will be the same as before.

However Obi Cloth will go from 30$ to 45$, but if you already own 2.x only 15$ will be charged to upgrade.

Also, we hope to start building our own community around Obi very soon, instead of relying on this forum thread. I´ll get back to you with more info asap.

Finally, thanks to all of you that discovered and reported a bug, requested a feature, or simply gave some insight on what they were using Obi for. Some names have beed added to the credits. But I´d also like to repay that in some more tangible way, so there might be surprises .

This is the final changelog for ObiCloth 3.0:

### Added
- Welcome window with automatic installer. No need to manually move resource folders anymore.
- Upgraded constraint projection to XPBD (extended position-based dynamics). This decouples stiffness and damping from the amount of iterations, resulting in more realistic simulation.
- Solver constraint enforcement order can now be changed. This allows to change the relative importance of constraints.
- The solver now uses a task-based threading system which allows to exploit parallelism between multiple solvers.
- Custom multithreading profiler, that allows to fine-tune performance.
- Optional local-space simulation with world-velocity injection, for better numerical accuracy in large-scale worlds and greater control.
- Support for painting per-vertex skin stiffness.
- Support for painting per-vertex tear resistance.
- Better data visualization for particle editor: particles now are drawn over a flat white version of the mesh, and paint mode shows the property gradient directly on top of the mesh (not only particles anymore).
- Added pencil paint mode to particle editor.
- Automatic self-collisions disabling for particles that intersect in rest pose. This allows to set larger particle radii
to ensure better self-collisions, without worrying about constraint fighting.
- Proxy component now works with skinned meshes. It is also much faster now, all math-intensive methods have been moved to C++ and parallelized.
- Breakable pin constraints.

### Changed
- Cloth component has been split in two different components: regular cloth and tearable cloth. This is because
regular cloth allows for extra optimizations to be made at initialization time. Also it prevents tether, skin and volume constraints from being used with tearable cloth, since they are not compatible.
- Actor particle limit is no longer 16384 but 65536, matching Unity’s own vertex limit.
- Particle editor paint brush falloff has ben changed from linear to gaussian.
- Distance constraints’ compression stiffness has been replaced by a slack percentage.
- Mesh updating is now done in c++, which results in better performance.
- Aerodynamic constraints have been reverted to per-triangle, as this removes the need to supply per-particle normals from Unity and allows the simulation to run as a closed loop in C++, which decreases memory transfers and increases performance.

### Fixed
- Bug that caused slow convergence and excessive jittering for particle-particle sequential contact resolution.
- Bug that caused out of bounds exception when trying to edit per-particle skin properties on non-skinned cloth.
- Bug that prevented the particle editor window from appearing on retina displays.
- Bug in aerodynamic lift force calculation, that caused way too much lift to be applied.
- Bug that prevented an already initialized cloth to be re-initialized with a different topology.
- Lots of small inconsistencies and minor bugs.

 

You should have link to the asset in your signature! I'm ready to buy it after a battle against my problem and now I have TWO whole click to do lol
I also guess there will not be mobile version of the asset?

Edit: BOUGHT! finally ...

 

Hi neoshaman!

Fluids and cloth both support mobile since 2.x, and mobile support for ropes will come in 3.x. So yes, all of them will support iOS and Android.

 

I'm a potential customer and I have a few questions about Obi Cloth.

For one, I am an artist and not a programmer and rely on Adventure Creator and PlayMaker.
It's been nearly two years since I have looked for a soft-body solution and I have some concerns.

Does Obi Cloth support PlayMaker?

Is there a chance Adventure Creator would be supported as well?

In my game, an adult one, I intend to have realistic penetration soft-bodies for male and female genitalia and is a crucial aspect of the game I am creating.
This would include penetration, flaccid and erect penis, breast grabbing, skin impact and so on.

Would any of this be possible with Obi Cloth?

 

None of this is even close to cloth behavior. Maybe try CaronteFX or Bullet or VertexmotionPro.

 

Hi Janet,

As wetcircuit said, a dedicated soft body simulator is a better solution for your use case. ObiCloth models soft bodies as balloons, that its, closed thin membranes full of air. They're way too soft for what you need them for. CaronteFX is a good solution if you can bake your simulations (that is, you don´t need realtime interaction).

cheers,

 

Hi. Can I just clarify this upgrade process please. If you already own Obi Cloth then you'll still get to keep 2.x but if you want 3.x then you'll need to pay $15 to get the upgrade? Otherwise if you don't pay you can just stay with 2.x?
Is that correct?

Oh and good luck with the new company, exciting times!