Hello,

I'm new to Obi Fluid and in the process of getting familiar with it.
I'm trying to have a very simple 2D scene, similar to 'Simple Fluid' in the Sample Scene folder.

I start a new scene, add an Obi Emitter (with solver), and turn it 90 degrees on the x-axis so it emits downward.
I then add an empty Game Object, and add 'Rigidbody 2D', 'Box Collider 2D' and 'Obi Collider 2D (Script)' to that object. As per the instructions, I make sure the emitter and game object are in different layers.

When I run the scene, two unexpected things happen:

1. The Obi particles 'enter' the object, i.e. they don't bounce off the surface, some of them even 'fall through' the object.



2. When I switch to 3D view, and have a look from the side, I can see the particles are not remaining in the 2D plane (z=0), i.e. they move backwards and/or forward once they hit the object.



Eventually I would like to create a simple bucket and fill it with fluid in 2D. How do I best go about this, so the fluid stays a) in the 2D plane, and b) in the bucket. Also, is there an easy way to fill the bucket when the scene gets executed, i.e. without having to 'emit' the fluid into it first, which takes a while?

Thank you!

Hi Obi Support team,

Wishing you a Happy New Year!

Our small team has recently purchased your Obi cloth plugin as we hope to implement the goal net animation of our soccer project.  Since the project is targeted on the mobile device, we have tested the baked simulation & it is running much more efficient on both high / low end mobile devices. 

However, we noticed the baked simulation couldn't work on the Samsung S3 & iOS with the Bitcode support.  We're uncertain whether this could be due to the hardware / software (e.g. Unity compatibility, Android & iOS C++) issues.

Hence, we are thinking whether the Obi Cloth simulation / baked simulation is possible to be converted to Blendshape animation that can be used in Unity or simply exported to 3D packages like Maya for editing & re-importing back to Unity later as this way can streamline the process to support more existing high / low platforms.

Looking forward to hearing from you

Thanks & Regards,
Peter

Hi, I love the fluid plugin and it works great on my computer. However, on my android device which is pretty new is struggling to get through the basics of my small scale fluid animation, I would appreciate it if anyone could tell me as many steps as possible to optimize the efficiency on mobile devices (im fine with a reduction in quality as i want my project to work on as many devices as possible) any and all tips would be greatly appreciated. Thanks!

Just upgraded my project to ObiRope 3.2.
But in this version ObiColliderGroup is missing.

Now my project is messed up 
- There is no ObiColliderGroup parameter in ObiSolver:
https://drive.google.com/file/d/1RRyZ-Lf...oI7Tg/view
- Pin constraints are gone
- Add Pin Constraint button does not work (clicking does nothing)
- Edit particles gives an error:
NullReferenceException: Object reference not set to an instance of an object
Obi.ObiParticleActorEditor.DrawParticles () (at Assets/_Tools/Obi/Editor/ObiParticleActorEditor.cs:332)
Obi.ObiParticleActorEditor.DrawActorInfo () (at Assets/_Tools/Obi/Editor/ObiParticleActorEditor.cs:598)
Obi.ObiParticleActorEditor.OnSceneGUI () (at Assets/_Tools/Obi/Editor/ObiParticleActorEditor.cs:262)

How do I fix this ?

Hi!

I read 'somewhere' earlier, before buying Obi Cloth, that it should work with Final IK. However, I cannot get it to work.

I am running the solver in LateUpdate.

I have a character, wearing a sash, which I'm trying to animate with Obi Cloth. It works, but problematically. With no Final IK enabled, it works as should. 
However, when Final IK is enabled, the part of the sash that is tied around the character's waist and should stay under his armour, constantly jumps (shows) above the armour in parts. Sometimes more, sometimes less. And when the character is going down a hill, for example, the part that should stay in place shows above armour and noticeably jumps up and down. 

Umm... some idea? Thanks.

Best regards, Laura

Hi –

I’m working on a scene made up of hanging chains of objects, each connected by a short rope: the first particle of each rope is pinned to an object at the top, and the last particle is pinned to an object at the bottom. The first object of the first rope is set to kinematic (to anchor the whole chain at the top). It’s all working pretty well, but I have a few questions.

The final scene will have lots of ropes; each chain contains about 6 ropes, and there will be more than 20 chains in total, so that means more than 100 ropes. Putting all of this together in the editor was impractical, so I’ve written a script (based on ObiRopeHelper.cs) to help automate the process. Script included below.

When the simulation starts, the rope springs like a rubber band that’s just been let go and then settles down. I'd like to have everything begin in a resting state (unmoving). In this thread: http://obi.virtualmethodstudio.com/forum...hp?tid=175 the solution suggested is disable the rope and wait for the next FixedUpdate before reenabling. I’ve tried to implement that in my script, but it doesn’t seem to be having any effect.

Next, I would like the ropes to be as non-elastic as possible. I realize that the recommended way of doing this is via tethers, but because my ropes aren’t fixed, tethers wouldn’t seem to be an option. However, in this thread: http://obi.virtualmethodstudio.com/forum....php?tid=6 there’s a method described in which the rope is fixed, tethers are generated, then the rope is unfixed. Once again, I’ve tried to implement this in my script, but it doesn’t seem to be having any effect.

I’ve therefore tried to set the rope length by using reduced values for stretchingScale (in ObiDistanceConstraints). I’m sure this isn’t ideal, but it basically seems to work (but maybe this is causing the initial rubber band behavior?)

Finally, I’ve found that each individual rope has to have its own dedicated solver; if I try to share a single solver across multiple ropes, Unity immediately crashes. I’m guessing this has something to do with removing and adding multiple pin constraints from the solver simultaneously/asynchronously? (Just a guess). Anyway, my question is whether there will be any problems (like a performance hit) by having upwards of 100 solvers in a single scene.

Hello, first off, I want to say how impressed I am with Obi Rope's performance, stability, and looks. You're doing a great job!

So I'm *attempting* to use it in a less traditional fashion to create something similar to a Grappling Hook Gun. The player fires a projectile which attaches to other objects in the scene, and the player then swings around (in 3D) using Obi Rope rigid body physics.

I'm currently stuck at even getting the projectile to fire from the "gun" with the rope attached to behave properly. I've pinned the ends of the rope to the projectile (rigidbody) and the player (rigidbody) and added a cursor to the players side.

I've done basically what's in the code below and was hoping it would do the trick, but the projectile seems to just spring back and act unpredictably. Not to mention the cursor length extension doesn't seem to keep up when used this way.

Title ^
I've restarted Unity, and it still will not keep any changes to my skin radius settings.

Is there anything that might cause this to happen? I don't consider redoing the whole setup to be a viable option.  

With the Unity's Cloth component still sucking(even after the 2017.3 update), I thought I'd bring up a couple collision-related things it seems to do better, in hopes that you might be able to add them.  

From my impressions, these are two features Unity Cloth appears to have that ObiCloth appears not to have:

1. Virtual Particles: Adds one virtual particle per-triangle to increase collision stability.
   
2. Normal-based Rejection(what I'm calling it): Unity Cloth seems to handle high-speed collisions far better, especially if they screw up, particles are quickly ejected along the closest surface normal(or perhaps the last encountered surface-normal they encountered). It also appears like there may be a position bias to this function so that collider's movement in-between physics time-steps is taken into account. At least, this is my impression of what it's doing.
   

I was wondering if there is documentation anywhere regarding the performance of obi on primitive vs mesh colliders. I seem to be getting a very noticeable performance drop in editor from subscribing to collisions on a mesh collider vs primitive colliders (tested boxes, capsules - all seem fine). Is this just a natural consequence of using mesh colliders- just seem strange, I go from 135 fps with primitives down to 40 fps with mesh collider, everything else being the same.