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

Thanks! and yep, that is correct. If you already own 2.x, you can just keep it, however no more updates will be made to it. If you want to upgrade to 3.x, you can do so by paying the 15$ difference.

Also, 3.x is not backwards compatible with 2.x prefabs, since most of the optimizations come from the way data is serialized. So if you have some cloth set up in 2.x for your project and don´t want to re-make it, it would be a good idea to stick with 2.x and only use 3.x for new projects you're about to start. Warnings about this backwards incompatibility will be written all over the asset description, update description, readme and manuals, though.

 

Small correction to this, looks like cloth.topology.heEdges should be cloth.topology.heHalfEdges

 

Oh, yiss! Thank you for your hard work I'll be the first upgrader

 

Any teaser videos for Obi 3.0? especially interested in Proxy skinned meshes.

Also with a particle limit of 65536 is that even useable? I am interested in offline rendering workflows as well as realtime, so a slow-but-large cloth-sim is still very interesting to me….

 

Hi!

There will be videos soon, I promise . I´ve tested 70.000 cloth particles in a pretty powerful quad-core cpu, and it runs at about 30 fps. However only distance constraints active, 3 iterations. So it wasn´t a complex scenario at all, just a stress test. I lifted the particle limit to match that of Unity's mesh vertex limit, because some users were using Obi for offline simulation (just like you) and there was no reason at all to put an artificial limit on the amount of particles.

The old limit came from the fact that each particle was rendered in the editor as a quad (4 vertices), so drawing them all using a single mesh meant only about 16000 particles should be rendered.

 

Hey man, I am having some issues, first when I click on Edit Particles everything gets super slow and nothing shows.

Also I have a bunch of errors. I just bought it, I am in version 2.2.2

Thanks!



NullReferenceException: Object reference not set to an instance of an object
Obi.ObiParticleActorEditor.OnSceneGUI () (at Assets/Obi/Editor/ObiParticleActorEditor.cs:181)
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:232)
System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
UnityEditor.SceneView.CallOnSceneGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:2034)
UnityEditor.SceneView.HandleSelectionAndOnSceneGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:1381)
UnityEditor.SceneView.OnGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:1218)
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)

 

Hi RenOli,

Follow the installation instructions you´ll find in either the readme or the quickstart guide. You need to move a couple folders around, as Unity won't find them unless they're in very specific locations.

cheers!

 

Thanks, that make it works.

However, still, lots of errors are going on.

Also proxy is not binding.

Thanks for the fast feedback.



ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
System.Collections.Generic.List`1[UnityEngine.Vector4].set_Item (Int32 index, Vector4 value) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:639)
Obi.ObiCloth.UpdateAerodynamicNormals () (at Assets/Obi/Scripts/Actors/ObiCloth.cs:762)
Obi.ObiCloth.CommitResultsToMesh () (at Assets/Obi/Scripts/Actors/ObiCloth.cs:642)
Obi.ObiCloth.OnSolverFrameEnd () (at Assets/Obi/Scripts/Actors/ObiCloth.cs:224)
Obi.ObiSolver.EndFrame (Single frameDelta) (at Assets/Obi/Scripts/Solver/ObiSolver.cs:564)
Obi.ObiSolver.LateUpdate () (at Assets/Obi/Scripts/Solver/ObiSolver.cs:679)

 

Make sure:

- Your cloth is a manifold mesh.
- Your mesh is has read/write enabled in the mesh import settings, and it has normals available.

cheers!

 

It is working now.

but I can't make it work with skinned mesh, the simulations doesn't work, at all, and when I hit play the cloth goes far away, without physics.

Bests

 

Hi Ren,

Write to the support email (you´ll find it in the quickstart guide), to avoid cluttering the thread. I´ll answer you there.

cheers,

 

I solved that problem, thanks

I have one question, I am using skinned mesh and the cloth has some thickness.. is there anyway to maintain the thickness of the cloth?

Does proxy works with skinned mesh?

(sorry for being so annoying) This really an amazing tool, really enjoying it.

Bests

 

I found out how to make it.

I just made the thick mesh as a regular mesh, and than binded, it worked.

However it seems that the cloned mesh is inverting normals

 

Humm.. actually it is not inverting the correct mesh. it is duplicating the mesh, adding to the binded mesh and inverting.

 

Hi Ren,

Simulating thick meshes is not supported, because its just plain impossible to simulate a thick mesh as cloth, since there aren't mesh edges *inside* the mesh, holding together both sides. Volumetric (closed) objects must be simulated as soft bodies, which Obi can only interpret as balloons: air filled thin membranes. If you went ahead to use volume constraints with a thick cloth, it would expand as you'd expect from a balloon.

Using the proxy component, thick meshes can be skinned to a flat mesh, which is the one carrying the simulation. However proxies currently only support non-skinned meshes. Obi 3.x (which is about to be made available) does support skinned proxy meshes.

cheers!

 

Thanks man,
I know it still doesn't have this functionality that I need for now, and I know it is not the tool problem, this is the games world limitations, but this is already an amazing tool, I was really trying to see how far I could go but already awesome. I will get Obi 3.x for sure.

Not only the tool is great, but also the support.

Thanks man, best of luck.

 

Hi! Here's a sneak peek at skinned cloth proxies, as promised:

This works by simulating a simple skinned mesh, and driving a more complex mesh using the particle output from the simulation. The simple mesh can be completely different from the mesh that is actually rendered, or it can be part of the same mesh used for rendering.

In this video, the trench coat is a thick mesh: the whole geometry was modelled flat, then extruded to give it a bit of depth, and pockets and other details were added to it. Then, the inside of the trench coat was marked inside Unity as the "driving" part of the mesh, and the rest of it (the outside, with pockets and all) is considered the "driven" part. You don´t need to manually split the mesh in two or anything like that, just paint which parts drive and which parts are driven. So by doing this, you ensure the simulation is stable (no face flipping, no self-intersections due to thickness) and also save quite a bit of performance by simulating only the driving part of the mesh.

The result runs blazingly fast, at nearly 220 fps in a Core i7.

I hope this will be useful for you guys!

 

Really cool, also what's the music?

 

Looks really cool. I'll probably be picking up Obi Cloth when this feature comes out.

Question. What happens if, when painting in the parts to be driven, you select every other vertex, or something? Does it still work? How about vertices from different parts of the mesh that are no joined up?

 

Yep, it works no matter what vertices you select. Driven vertices are "attached" to the driving triangle that gets the maximum score in a test that considers:

- Barycentric coordinates of its projection in the triangle.
- Distance from the triangle's surface.
- Orientation of vertex normal vs triangle normal.

So the worst that can happen in case the driven vertices have no nearby driving vertices, is that they get skinned to far away parts of the mesh and it will look weird.

However, to avoid cases where vertices attach to parts of the mesh that aren´t supposed to attach to, you can also control which vertices are supposed to drive which vertices, using a 32-bit mask. It's not a boolean on/off thing

 

I messed up the terminology in my last post, sorry. I meant to ask about the driving, simulated vertices. Do those have to join up together contiguously?

Also, what about the arms? What stops them binding to the simulated mesh at long distance? It looks to me like the mesh is divided into three, the simulated part, the driven part, and the regular skinned part. Is it possible to blend between the driven section and the skinned section? Or is it on/off per vertex?

 

No, the simulated vertices do not need to be all joined up either.

About arms, you can use the bit mask I mentioned to ensure they only consider simulated vertices in the arms, and they don't bind to nearby torso vertices. Basically you can paint several sets of driving/driven masks, and they don´t interfere with each other. In the sample video for instance, the left side and the right side of the trench coat use different masks to avoid vertices in one side to binding to particles in the opposite side, which would look terrible in the gap at the back of the trench coat.

The simulated part and the driven part are specified using these masks. Any vertices of the mesh that have no masks set are considered to be 100% skinned, and thus are not simulated at all. For the driving vertices, you can use skin constraints to specify a maximum radius and backstop values so that they stay close to their skinned position. So yes, you can blend between 100% skinned (0 radius) and 100% simulated (large radius).

At the end of the video, in the part where I´m using the editor, you can see: skinned particles (red ones), simulated or driven particles (blue ones) and blue normal lines that represent the maximum radius around their skinned positions. Particles near the waist have progressively smaller radii, so that they "blend" between the top part of the trench coat, which is completely skinned, and the bottom part which is simulated.

cheers!

 

Sounds good! So when's it coming out?

 

Hopefully we will be able to upload it to the store at the end of this week. From there, it's up to the guys at the store, it depends on how much it takes for them to approve it.

 

I wonder if we can remake a Marvelous designer lite with obi

 

I'm trying to import clothes designed by the Marvelous designer into Unity. However, if the cloth consists of various parts (and some parts shared the same edge), these parts will animate independently to separate. If I export the cloth as a single mesh, the Obi cloth will throw an error that "Your mesh is non-manifold". How can I make the cloth animating as an intact object correctly? Thanks!

 

Hi Nick!

if your mesh is non-manifold, it means it has some sort of topological error somewhere:
- Adjacent faces facing opposite directions.
- Disconnected vertices.
- More than 2 faces sharing the same edge.
..etc. Anything that would make the resulting shape to be "impossible" to exist in real life. Triangle soups usually suffer from this, as their topology isn´t very clean. The only way to fix this is to either feed the mesh to a mesh cleanup tool (such as the ones in Maya or Blender) or figure out where in the mesh the problem resides, and fix it manually using modeling tools.

 

It could be . Afaik, Marvelous uses an implicit integrator which doesn't try as hard to be real-time, but offers better convergence properties. Which broadly speaking means it's easier for them to get inextensible cloth, but the cost per simulation step is higher.

Also, they have much more precise collision detection, as they don't need to be realtime, just fast enough.

cheers,

 

Arkano - Love seeing the improvements in your simulation, particle based simulation is quite amazing! Just was wondering if you could answer a few questions.

A while back you said the collision was based on distance fields, is this still the case or have you found something better?

Second, I also seem to remember you saying that there was a soft body system in the works that could be used to model the deformation of stiff objects. Super curious what strategy you were going to use to do this, seems like it can be done using mass spring systems or by finite element analysis, were you going to use one of these two strategies?

Thanks a ton, your work is inspiring!

 

Just a tangent, what do you think about this? Where is the catch?

 

Hi neoshaman!

None, there's no catch in there. It is an iterative solver (the same kind used by Obi, actually) but implemented in GPU, and with an insanely high amount of distance constraint iterations to prevent stretching. This is possible because the GPU is much more well equipped for parallel execution than the CPU.

However, you do need compute shader support to run it and a pretty powerful GPU, which excludes a lot of low-middle class devices. So that might count as the "catch": desktop, windows only stuff.

Assuming you want to do cloth at this level of detail, there's a smarter approach to reducing stretching in the general case, and that is to use a multigrid solver. Iterating over all constraints a bazillion times like this guy does gives diminishing returns (the more times you iterate, the more processing power you use for a smaller improvement). Multigrid solvers pack a lot more punch for a given amount of iterations.

 

Hi macdude!

Distance fields were used to replace MeshColliders in the first version of Obi. Since then, I've moved on to direct triangle-based collision detection: the mesh collider geometry data is pre-processed into a hierarchical form, that is directly used to check collisions against. This is certainly not faster than using distance fields, but it is more accurate, uses a lot less memory and it is way easier to set up for the user.

For the soft body system I´m using a technique known as shape-matching.

cheers!

 

Hello, @arkano22
How's the new Obi Rope version going on? When will it be updated?

 

For starters, I want to say again, I LOVE USING OBI.lol, but I've been running into an issue with my obicloth fixed portion dragging behind my character when he's running, when using Ootii's Motion Controller.

Motion controller which adds colliders at runtime, may be the issue, but I wonder if there could be a change made to have Obicloth only interact to colliders we drop in a list, that way it could ignore any others.

 

Hello, @arkano22, I was looking to add your cloth system to my game for some of my characters, and I would love to know if you have any tools that will aid in the painting of cloth influences... how is the performance for cloth sim on characters with skinned meshes? Do I still have to use colliders, or could I use parts of the character for collision, like in a 3d app? Looks really good man. I might end up getting Obi Cloth and Rope.

 

Hi electric jesus!

Still working on 3.x for all three assets, cloth, rope and fluids. Ironing out bugs has taken more time than I expected. Cloth has just been finished and will be uploaded at the end of this week. Rope and fluids will take at least a couple weeks more.

 

Hi kurotatsu!

Unless I´m missing something, that's precisely the way Obi works! You add colliders to the ObiColliderGroup, and only the colliders in that list are considered for collision with the particles in whatever solver(s) are using that group.
Let me know if you had something else in mind

 

HI KR Graphics!

There's a whole custom editor integrated that allows you to paint cloth skinning influences, and not only that, but any per-particle cloth property: mass, collision radius, etc. You can do so directly in Unity's scene view.

In 2.x (current version), performance for skinned characters is ok, but nothing too impressive. A couple characters (1000 simulated vertices each) can be simulated at around 50 fps. In 3.x (which will be out in max 2 weeks) up to 5 chars can be simulated at around 100 fps (2500 simulated vertices each).

If your characters are animated, you'd have to either use skin constraints (which are good for cloth that is close to the body under all circumstances, like a shirt... they offer robust collision detection without the need to set up colliders) or use regular colliders parented to the body for things like capes, trench coats, etc... which can collide with parts of the body which aren´t close to the cloth in the character's bind pose. Direct (and robust) collision with a deformable mesh in realtime is still out of anyone's reach.

cheers!

 

Just out of interest. Is there any sort of guidelines for what's a good number of simulated vertices per simulation? Is computation time basically linear with vertex count or is there any sort of sweet spot maybe? Like maybe they get calculated in asynchronous batches or something.

I'm really looking forward to trying out 3.x when you release it btw!

 

+1 for version 3.

When ya got a decent beta, I'd like to try it, I can PM you my invoice #.

 

This might pose some issues... especially when I have characters that are about 90k a piece. One of my current designs will most likely combine the two and force me to split the overcoat to use as a separate mesh so I can have collision detection on it... the tools looks great and robust and I will most likely use it.

 

I'm getting this error when I try to make a build:

Shader error in 'Standard (BackFaces)': invalid subscript 'boxMax' at Assets/Obi/Resources/ObiMaterials/UnityStandardCoreBackfaces.cginc(243) (on d3d11_9x)

Compiling Vertex program with DIRECTIONAL
Platform defines: UNITY_NO_SCREENSPACE_SHADOWS UNITY_ENABLE_REFLECTION_BUFFERS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING SHADER_API_MOBILE SHADER_API_DESKTOP UNITY_COLORSPACE_GAMMA

 

Hi KRGraphics,

There's absolutely no way you can simulate 90000 vertices in realtime, no matter what simulator you use. Most GPU based simulators have issues with less particles (around 60000 in my tests), more so for a CPU based one like Obi.

Splitting meshes to have a separate mesh for cloth is a good idea in terms of performance, but not a necessity. Since you can paint which particles (vertices) are simulated and which not, you can focus computational resources in the part of the mesh that is actually simulated, and skip most of it where it is just driven by animation.

cheers!

 

Hi kurotatsu,

Unity 5.5 introduced backward-compatibility breaking changes in shaders. So the double-sided standard shader included in Unity needs a revamp. Find the updated version attached, place the files included in Obi/Resources/ObiMaterials

cheers!

 

Hi there Zomby!

Computation cost grows linearly with the amount of edges in your mesh. For sane meshes (where each vertex has a valency of 4 to 8) this is approximately equal to linear cost in the amount of vertices, just with a higher constant factor.

Obi 3.x has task-based thread scheduler which generates a DAG of tasks, many of which can be processed in parallel. Small meshes get their own task each, very small meshes are grouped into a single task, and big meshes are split into several tasks (when possible). This way workload gets evenly distributed across all cores in your machine, so you don´t have to worry about this sort of stuff. Things will always run as fast as they possibly can.

Obi 2.x generates a task for each mesh, regardless of its size. So this is a bit of a suboptimal solution, since many small meshes generate way too many tasks and thread management costs begin to be higher than the actual simulation cost, and big meshes do not benefit from multithreading at all. Also tasks are created statically, so no dynamic workload balancing takes place and multiple solvers are not executed in parallel, only tasks within each solver benefit from multithreading.

 

That is the plan . And I meant 90k for overall poly count... hopefully I'll have Obi to test on my character soon.

 

Thank you I'll try it out.

In the mean time, you might want to include that zip with a readme in Obi's base folder, so others may have that fix as well.

 

Hello arkano22,

I was wondering, is your cloth system updating direction of imported normals from the mesh or does it generates it's own smoothed normals like Unity's cloth? It's absolutely neccessary for my mesh to keep it's own normals after the cloth is applied as I use normals to achieve very specific effects and they have to be kept as they were designed in moddeling program.

I also assume that other information like additional UV's and vertex colors are left unaffected by Obi?

 

Hi Grosnus,

The current version (2.2) does calculate its own normals. However in 3.x (almost out) you can choose whether to recalculate normals, or skin (rotate) the original ones along with the tangents, see attached screenie. This will keep your original normals intact, at a slightly higher cost. If you need this functionality, I'd say wait for 3.x.

Colors and all uv channels are left untouched in both versions. For tearable cloth, colors and uvs are copied from the original vertices to the newly created ones to ensure continuity.

 

That's really great news, the additional performance cost is absolutely understandable in this case. I am from Gloria Victis team and would love to try the system out in our project and see how it blends with our workflow. How soon can we expect 3.x? It would be a real game changer for us.