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

Hi Hopeful,

The price will stay the same, now and always. There's no upgrade fee at all.

My business model is to "chop" the unified particle solver underneath Obi in several assets, each one targeting a different kind of simulation: cloth, ropes, rigid bodies, fluid, gas, etc. Each one of them will have a different price (most around 30$, some will be cheaper, some slightly more expensive). But once a price tag is set for each of them, it can only get cheaper.

 

It'd be really impressive and imo beneficial to show a couple examples of the intercollisions support, especially on a character.

Awesome job arkano22.

 

Exciting @arkano22 ! Looking forward to seeing the update on the asset store.

Do you have a sense for comparing the performance impact of Obi Cloth 2.0 vs Unity Cloth for the character/avatar clothing use case? Let's say I'd want comparable cloth movement quality between the two, but I'd want the ability to keep clothing from clipping with itself. (I'm not as worried about it exerting force on other objects.)

Also, how do you apply cloth behavior parameters to the vertices? It's been a while since I've done that with Unity Cloth, but at least in the past, it's been rather unwieldy. If Obi Cloth makes that process more convenient (or will in the nearish future), I'd probably switch to it vs Unity Cloth just for that reason, if performance is comparable (or better in Obi's case).

 

Thanks Anmator2d! in the video I posted you have intercollisions going on between the balloon thingies at the end, as they bounce off each other. They work exactly as self-collisions do, but between different cloth pieces.

Previously this was not possible to do because each cloth piece only knew about its own particles, and they were simulated in local space. 2.0 does all the simulation in world space, and there's a new Solver component which allocates and manages particles for several cloth objects. Thus under the hood, there's no distinction between particles belonging to different objects, and intercollisions just emerge from the fact that particles collide with each other and they're all simulated in the same space.

 

Hi chiapet,

I do not have exact numbers (yet), but self-collisions and inter-collisions are quite cheap in Obi, and they will prevent your cloth from clipping.

Cloth parameters can be applied in two ways: One is using the included particle editor, which is similar to Unity's one. That means it is quite annoying to use except for a few quick adjustments . In 2.0 you can also load texture maps containing this per-vertex info. These can be either used in the editor in an offline fashion, or used at runtime to change cloth properties on the fly. This way your cloth data is stored in textures and you can edit in in photoshop or whatever you use.

I expect to improve both systems over time, and I´m open to suggestions. In fact the texture-loading idea came from someone in this forum (I don´t remember his/her name -_-).

 

Oh man, the texture map idea alone is enough to sell me on it. Screw awkward vertex selection or brushes! Thanks for the prompt response!

 

I didn't read the full topic, but this texture map solution is fantastic! You should mark it in the trailer video and/or feature list

 

Great to hear it's submitted to asset store!

Is it safe to assume that previous OBI features are still in? Like tearable cloth?

 

Hi Tasmeem,

Yes, all old features are in, EXCEPT distance field colliders, which will be re-included later. This is because they need to be rewritten on the C++ side for efficiency, and they are quite complex guys (mainly due to the compression algorithm they use). I didn`t want to rush them or delay the release further for only one feature.

Tearing, capsule, sphere, box and terrain colliders are all there. All old constraint types are back as well, velocity damping uses a new -faster- algorithm (standard velocity dampening instead of center-of-mass viscosity), and particle sleeping has been removed because it caused more problems than it solved.

 

Here's a quick look at the new texture property loading tool:

The "Min value" and "Max value" parameters in the tool allow you to specify a range mapping between pixel intensities (0-255) and property values. So if you set Min value to say, 3, and Max value to 7, black pixels will be mapped to a value of 3 and white pixels to a value of 7. Hope that makes sense!

You can also select which channel (r,g,b,a) to read from, and you can mask out unselected particles. This way a single texture is often more than enough to encode all properties of your cloth, since you can reuse the same channel for several properties if you wish.

 

Hi again,

Several people have asked me about the possibility of using Obi to do something similar to what was described in a Gamasutra article titled "The secrets of cloth simulation in Alan Wake", to which I steered them myself. Their technique involves using a low-res cloth simulation to drive a high-res mesh.

Nvidia Apex also does this to an extent. Since it is a very useful (and simple) technique when you have things like non-despreciable cloth thickness, garments with pockets, buttons, creases, belts... it will be available in the first update after 2.0.

The workflow is really easy: you just put both meshes (your simulated cloth mesh, and the mesh you want to be driven by it) on top of each other, add a ObiClothProxy component to the driven mesh, and click "Bind". What this does internally is generate a quaternion-based linear blend skinning between both meshes. This is much quicker to evaluate than a full simulation of the hi-res mesh, imposes no restrictions on the shape or details of the hi-res mesh, and keeps it from looking like a triangle soup (which is what happens when you naively add cloth simulation to a closed volume).

Video or it didn't happen:

 

Looking forward to that binding feature. Sounds wonderful!

 

Hi again guys,

As you already know, Obi will comprise several modules, each one of them tailored to a specific kind of simulation: cloth, fluids, soft bodies, etc. I'm announcing the second module, which makes use of the same core solver as Obi Cloth: Obi Rope. Here's a quick preview, starring a sticky sphere and a handful of tentacle-like normal mapped ropes:

Obi Rope 1.0 is in the final stages of development and will be sold separately for 25$. When used together with Obi Cloth you'll benefit from interacting / colliding cloth and ropes, and some additional features that involve both modules (like stitching cloth and ropes together to make, for instance, a completely simulation-driven functional parachute). It will feature:

- Procedural rope mesh generation based on splines. You just define a spline, click "Initialize" and your rope is ready for rendering and simulation. Several ropes can be made from the same spline, and then moved to anywhere else.
- Two-way interaction with rigid bodies. You can use them to hang a lamp from the ceiling, for instance.
- Rope self and inter-collision.
- Collision friction and adhesion.

And lots of additional features inherited from Obi Cloth, like aerodynamics, bending constraints, etc. In a few days it will be uploaded to the store.

Hope you find it useful!

 

Dear Arkano!

Just updated to 2.0 from store, and I'm getting these errors:
Assets/Obi/Scripts/BroadPhase/ObiActor.cs(12,14): error CS0101: The namespace `Obi' already contains a definition for `ObiActor'
and
Assets/Obi/Scripts/ObiCloth.cs(50,21): error CS0101: The namespace `Obi' already contains a definition for `ObiCloth'
Also, the Obi components not show up, when I want to add them. I'm not so good in programming, and beginner with Unity, so... Maybe there is an easy and obvious solution. I didn't find a thing, when I googled it.

Thank you for your patience and time and for the hard work.

 

Amazing can't wait!

 

Hi Varga,

It seems you have installed the new version on top of the old one, which is incompatible. Just remove the whole /Obi folder from your project and install the package again. That should fix your problem.

cheers!

 

Oh! I just deleted them inside Unity, and they were still there! Thank you for your fast reply

 

Well... The error messages have disappeared, but I can't make it work :/ Everytime I run a simulation, my Unity Editor stops responding. I have started new projects, stopped other softwares, but not managed to get it work. The scenes run 1-10 secs and then freezing the Editor.

 

Hi Varga,

Yes, i´ve got three reports now of the same bug. One guy contacted me through the support email, another one trough the youtube channel, and now yours.

After a fun debugging night, I found the bug itself seems to be an access violation when using more than 2 cores in certain windows computers. Attached to this post you´ll find a single-threaded version of the Win plugin. Replace the x86 and x86_64 folders in /Assets/Obi/Plugins with the ones you´ll find in the attachment, restart Unity, and it will work.

However this is a temporary solution only, as running in a single thread is far from ideal as it doesn´t take advantage of multiple cores. I am not able to reproduce the bug in any of the three Windows computers I use for testing, so I´d be very, very grateful if one of you guys helped me debug it. I´d only need you to test a few compiled projects for me, and report back the results. Wanna help, Varga? Can anyone else help?

cheers!

 

Thank you for the plugin. The Benchmark scene is working, and I think it is a bit faster - even if it is using a single thread. I started a conversation with you - is it Private message here in Unity Forums?

 

You mentioned that the cloth object can be deactivated, moved around and reactivated when teleporting objects.
Do you just use it like this: cloth.enabled = false; transform.position = Vector3.Zero; cloth.enabled = true;
Because I'm still noticing strange cloth behaviour doing it this way.

 

Hi Baznor,

Yes, but you have to wait until the end of the frame (specifically, after the solver's LateUpdate) to re-enable the cloth. The trick is to deactivate the cloth at the beginning of one frame, move it around as much as you wish, then re-enable it at the end of the frame.

You can use Unity's WaitForEndOfFrame for this.

The reason for this is that the solver needs a chance to stop the simulation at a proper point, not just mid-frame, before being able to resume it elsewhere.

 

Hi @arkano22,

just bought your asset but having zero fun with it . I imported the asset into by project and followed to readme and guide to move the folders to their proper places. Opening any demo scene provided and pressing play stalls my Unity session. No error occurs but after 5 minutes wait I'm killing the Unity process.
So I tested it in a completely new project: same thing happens, Unity stalls.
Looking at the log I notice some missing referenced scripts:

Spoiler: Log substract

(Filename: Assets/Obi/Sample Scenes/Buoyancy.cs Line: 87) Buoyancy:Start() (at Assets\Obi\Sample Scenes\Buoyancy.cs:87)UnityEngine.Debug:Log(Object)UnityEngine.Logger:Log(LogType, Object)UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])UnityEngine.DebugLogHandler:Internal_Log(LogType, String, Object)[Buoyancy.cs] Name="Ship" volume=0.1, mass=20.0, density=300.0Load scene 'Temp/__Backupscenes/0.backup' time: 98.776962 ms (Filename: C:/buildslave/unity/build/Runtime/Mono/MonoBehaviour.cpp Line: 1655) The referenced script on this Behaviour (Game Object 'Mast') is missing!(Filename: C:/buildslave/unity/build/Runtime/Mono/MonoBehaviour.cpp Line: 1498) The referenced script on this Behaviour is missing!(Filename: C:/buildslave/unity/build/Runtime/Mono/MonoBehaviour.cpp Line: 1655) The referenced script on this Behaviour (Game Object 'ClothSheet') is missing!(Filename: C:/buildslave/unity/build/Runtime/Mono/MonoBehaviour.cpp Line: 1498) The referenced script on this Behaviour is missing!

I'm using Windows 10 Pro and Unity 5.3.2p

 

Turned out that this is a bug, Arkano is working on it. He is provided a single-thread version of plugins earlier this page. It is not the solution, but temporarily works.

 

@VargaPD: How did I miss that? (will need some extra strong glasses) Indeed replacing those files do allow me to check out the asset.

 

Yes Cynus, as Varga said it is a bug. And a quite elusive one... for now, all I know about it is that it happens due to multithreading and not in all computers, so it must be some sort of thread synchronization issue. The obvious workaround was switching multithreading off, at the cost of performance of course. I´m working on it, and will update Obi asap.

Its a shame that the Asset Store doesn´t allow publishers to temporarily take down an asset without completely removing it, as right now most Windows users will have the problem you describe. And even though I posted a temporary solution here, searching the forums for it is not an easy/obvious thing to do... :S.

 

If you want I can test any fix, for my project I need definitely some clothing and I'm targetting Windows. So if I can help just let me know.

 

Did some testing and while everything seems to work fine, adding a meshcollider to the Obu Collider Group will cause Unity to stall, forced reboot needed. Removing that collider from the group, replacing it with box colliders approx matching the shape does run smoothly. Maybe a warning when assigning a mesh collider to the group would nice (if that isn't supported) or did I strumple upon a bug?

Edit: some problems occurs when using a character controller.

 

Hi Cygnus,

Yes, mesh colliders aren´t supported but a quick test here caused no stalling. Maybe it is another bug, I´ll look into it.
Can you elaborate a bit on the problems using a character controller?

cheers!

 

Hi Arkano22,

I mailed you a pdf (to your gmail account) containing steps to repo, my specs and the latest log produced by Unity.
Hope this helps pinpointing the issue.

Kind regards

 

Hi,

Both bugs, the one hanging Unity in Windows and the one reported by Cygnusprojects have been fixed and an update has been submitted to the Asset Store.

Turns out, the first one was not a bug in Obi itself but in the compiler used to compile it for Windows, or more specifically, their standard library implementation (which is the last thing to check for when debugging, as it is really uncommon). Just switching to a different compiler resolved the issue. If you guys find any more bugs, report them and they'll be fixed asap.

The new version also includes support for character controller colliders, and the ObiClothProxy component.

Edit: here's a video showing how to set up cloth proxies. Note that only regular MeshRenderers can be used as proxies for now, no SkinnedMeshRenderer support yet.

cheers!

 

That feature (using a proxy mesh to deform a denser mesh) is fantastic!

 

Hi! Picked this up yesterday and it's a fantastic addition to my toolset. My question though is weirdly specific, and seems like something that can be done but I can't quite figure it out. My end goal is to be able to pick up a piece of cloth by one corner and move it around while the other end is still fixed/attached at the other end. It seems like this could be achieved by using a pin constraint and moving the pinned object through user interaction but I haven't been able to get the desired effect. Any pointing in the right direction would be a huge help, thanks!

 

Hi streetalchemist,

Yes, you can do this using pin constraints. What is your specific problem, setting it up or getting it to behave as desired? If you want, you can PM me or email me (you´ll find the support mail in the .pdf guide) and I´ll walk you trough it.

If one end is fixed and the other is moved by the user, with no rigid body interaction at all, you could also use fixed particles and move them by code directly. I can also show you how to do this, if you´re used to coding it is pretty straightforward.

 

Just sent you an email with a better description of what I'm trying to do, thanks so much!

 

Dear Arkano!

Does the feature in the attached picture still available in 2.0, or will it be added later, or it will be in another Obi project (like Obi Ropes)? If it's in 2.0, how can I achieve this soft body effect?

 

That particular effect was accomplished using high damping and zero gravity (or negative gravity). You might want to use bending constraints too.

cheers!

 

Thank you, I have managed to almost reproduce it. Some tweaking and it will work

Just one more question. You wrote 'Note that only regular MeshRenderers can be used as proxies for now, no SkinnedMeshRenderer support yet.' Does that mean, that you thinking in use SkinnedMeshRenderer proxies too? That would save me serious time in my project, if it won't consume much more resources than MeshRenderers does.

 

Yes, the idea is to support SkinnedMeshRenderers too, in order to be able to get a low poly skinned cloth to drive another. Complex character clothing will benefit a lot from this .

 

Hi guys,

Quick update. Bad & good news.

Bad news first: version 2.0.1 was rejected by Unity because it crashed in some of the Windows computers they´ve used for testing, which means two things:
- they actually test assets thoroughly, which is
- the multithreading bug in Win is still there, despite all the people using the "fixed" version seem to have no issues at all. So back to the start...

Good news: OpenCL (GPU) support is already well underway and has started to show massive performance improvements.

cheers!

 

Hmph... So I can't help now? Also, how did they missed it in 2.0.0 if they ran tests?

 

Omg GPU support sounds too awesome!

 

I would suggest you just switch the whole thing over to opencl. What version of opencl are you using if it is a version that can also run on the cpu then you could just replace you existing c++ code with it and run it on the cpu for people that don't have a decent gpu. That might also solve your strange issue on pc with the compiler.

You might even want to get fancy and make a vulcan version of it in future by compiling your opencl code to spirv for even higher performance on pc , linux and android.

 

I'm not really on top of these more technical things, but I find it a little funny that c++ is too glitchy and opencl is the solution. Did we cross into a parallel universe at some point?

 

I´m targeting OpenCL 1.2. I´ve made a single kernel abstraction on top of it that can execute kernels written for OpenCL or written in plain c++. The idea is to provide one kernel implementation for each platform (OpenCL, plain CPU, maybe CUDA in the future?) and let it run in whatever is available. Not everyone has working OpenCL drivers, so it might fail to work and a regular c++ fallback is desirable, I think.

I love the idea behind Vulkan. No support in OSX afaik, and slow adoption in other platforms makes portability suffer imho. I´m not up-to-date on this so I may be wrong.

 

Well, it´s not that C++ is glitchy. It´s libstdc++'s implementation of thread synchronization primitives whats glitchy. And when you try to use the (comparatively better) libc++ in Windows you find out that mingw doesn´t support it and clang is not exactly easy to get up and running. All in all, there's no reliable way of using C++11 threading stuff in a portable way, not that I know of.

OpenCL was not intended to be the solution to this, as I was working on it way before running into the whole Windows threading issues. But if it turns out to work well, it will outperform threaded CPU code. If I cannot fix the threading issues before getting a stable OpenCL implementation working, then there's no point in fixing it.

 

Hi Varga,

The fix I included in 2.0.1 seemed to work for you, as well as others. However it doesn´t work for them... and I even sent them the package again to make sure they were testing the correct thing. Either they didn't test 2.0, or they tested it and the error did not appear in any of the computers they used.

Thing is, I haven't been able to reproduce it yet, in any Windows computer i´ve tested on (quite a few by now). So all computers I have access to, directly or indirectly (yours) run it perfectly. I have to find at least one that crashes consistently in order to locate and fix the bug. The issue has to be related to std::condition_variable, as I can get that code running when compiled with libc++, but the exact same code compiled with libstdc++ crashes. So I have to either find a way to compile using libc++ in windows, or refactor the code so that it doesn´t trigger the error in libstdc++ .

 

Hi @arkano22,

Do you know the test setup Unity has used to validate your asset? I was wondering may me (and others) could try to reproduce (if we know what we have to do that triggers the crashes at Unity) because as stated before the 2.0.1 version is working perfect on my end.

 

Just wondering, what is the possibility that your rope simulation could be used to simulate a pulley? Could you possibly test it? Thanks!

 

Sure! However i´m not too confident it will be able to lift heavy weights without cranking the settings way up. I´ll test it out.