Hello! I'm trying to use the Rope package in order to make a slingshot to launch a sphere. However, it doesn't work. First the rope wasn't bending enough, so I tried fixing it with the stretching scale value in the Obi Rope class, but then the rope was too loose and it didn't "jump back" to launch the sphere.

The sphere movement is implemented with a RigidBody, and it's using the Obi Collider component for the collision detection. I'd appreciate it if you could help fix the rope so it behaves as expected.

These are the components:

Rope Object:



Sphere:



Slingshot Blueprint:



Solver:



This is what it looks like now:
 https://i.gyazo.com/22466f214ef57e70ad0547e74336160b.mp4  

I have a hat which is controled by obi softbody (because it needs to be stiffer than the cloth simulation can do without a lot of iterations), the brim of the hat has a ribbon which dangles from it. 

Im controling the ribbon with Obi cloth, and need to stitch the ribbon to the brim of the hat. However when generating the hat blueprint, the particles are not accurate to the verticies of the visual mesh like they are when using obi cloth, so the ribbon cannot be placed in the correct position.


This can be improved a little bit by reducing the anisotropy neighbourhood, which brings the particles closer to the edge of the brim, however it causes the particle orientations to mess up if i do that. 
Do you have any advice for dealing with the situation?

Have been using the Obi tools for a few weeks now, it's a fantastic set of tools and the softbody particle simulation is kind of genius. I've been exploring various use cases for a game in development and have noticed a few bugs and issues and had some and some features that would be great to see implemented.

Bugs and issues:

1. Obi Emitter Min pool size doesn't work when set to 1. Fix is to swap the > on ObiEmitter.cs line 462 for a >=.
   
   
2. Obi Emitter speed variable for flow rate doesn't work well for very low-resolution fluids (e.g. 0.1 resolution). I've found a few cases where decoupling emission force and emission rate was useful.
   
   
3. Certain settings can make the solver lock up and you have to kill the Unity process. I know this isn't an easy one, but is it possible to have the solver stop and throw an error if the process is taking too long?
   

1. Alternative phase system: The Phase system for filtering which particles interact with which colliders feels kind of reversed, we can only select one phase to NOT interact with so there's no way to limit specific particles to a specific collider. Is the current implementation necessary for a performance or stability reason?
   
   
2. Random emission: Obi Emitter shapes generate a distribution of points to spawn particles at, and it emits particles at them sequentially, resulting in predictable patterns. Could we get an optional pseudorandom distribution order? Possibly do this at the distribution point generation time to minimise performance issues?
   
   
3. Manual EmissionMethod: The current system is great for continuous or burst emission of fluid, but to integrate it with most games will require programmatic emission of a controlled number of particles. It'd be good to add a Manual emission type where it doesn't emit until a method is called to emit a specific number of particles.
   
   
4. More particle kill methods: Right now all particles must have a life span set and are killed at the end of that. I'd love to get some alternative kill methods, like if I could emit 100 particles with no kill time and then manually kill them later, or maybe make particles killed by velocity or collision force or minimum connections (like individual disconnected particles self-destroy). Just feels like there's a lot of room for expansion here.
   
   
5. Convert fluid to softbody blueprint: This is a bit of a crazy one, but could we get a way to solidify a set of fluid particles together in their current shape, or to make them transform into a shape provided by a softbody blueprint?
   

Obi Softbody's surface blueprint generation seems to do a good job on high-poly models with consistent vertex density, such as the example models of the dragon or the bunny. Unfortunately, it has big problems with any reasonably optimised models.

The main problem is that when generating a surface blueprint for a mesh, Obi is fundamentally limited to generating a maximum of one particle per mesh vertex. If the model has vertices that are not regularly spaced, then you run into problems when setting the Cluster Radius. The areas of the model with more densely packed vertices become overconnected for any given cluster radius value, and less dense areas become underconnected or even disconnected.

I wanted to see what can be done to combat this, so I just have a few questions if anyone knows:

1) Is it possible to generate intermediate particles on edges or faces rather than only on vertices?

2) Is there a better method for connecting particles than cluster radius?

3) Is it possible to limit the particles to the closest 3-4 connections to prevent over-connection?

I'm trying to get a skinned cloth simulation working on a character that's using the FinalIK "Grounder Full Body Biped" component.

The Grounder component pulls the character's pelvis and legs down so that she's properly "grounded" on uneven and sloped surfaces. But this means that the character gets pulled away from her gown when she's on those surfaces.

Here's what things look like "ungrounded":

   

And here's with the grounder component enabled:

   

If I disable ObiCloth, the gown does get skinned correctly. (It looks absurd, of course - but you can see that the waist of the gown doesn't get hiked up above the character's waist.)

   

Is there an obvious solution to this issue? Is this some order-of-operations thing? Like, maybe the Obi simulation is running after the FinalIK simulation?

A feature I have implemented myself is the ability to define a maximum number of particles a rope can possess when it generates.

One thing I noticed during testing is it is easy for the player to accidentally select two very distant points when deciding to join them together with a rope. For example, point A is at your feet, and point B is on the side of a distant mountain. Even with a modest resolution of 0.1, it'll quickly bring the game to its knees as expected.

Now that surface-based collisions are a thing, it seems especially appropriate to allow hard limits on the number of particles when they are converted. For premade blueprints, it'd make sense to not include this feature since you can determine ahead of time how many particles will get generated. Though for player-made ropes it can get flaky.

I figured since you liked at least one idea I had, I thought I'd share this one. It's at least the least controversial idea I have currently. 

(This could also apply to other types of actors.)

I've set up a rope that is completely linear - the start point, end point and tangents are all in a straight line.

I've temporarily removed the [HideInInspector] tags on the field "ObiRopeBlueprintBase.m_RestLength" so I could see its value. Looking at the code, it appears to represent the total length of all the segments in the rope as measured from the distances between connected particles. However, the rest length value displayed was very off.

The start and end points were exactly 2m apart, but the rope's reported rest length was reported to be 42!
On top of that, changing the resolution will cause the rest length to change anywhere between 202 (at a resolution of 0) and 6.878044 (at a resolution of 1).

I looked through the code can't make sense of why it'd come up with wildly unexpected values on a linear rope. Even if the rope was curved, the length should increase with resolution, not decrease.

Is it measuring the length of the rope relative to something else?

I'm completely new to this asset and I have a problem that I cant seem to find a way to solve it. 

I want to have a hook at the end of the rope and when that hook comes in contact with an object it attaches to that object and when the player pulls on the rope, the object comes wit it. 
My first instinct was just to make the object a child of the hook but that doesn't seem to work, the object either does not move or glitches out. 

Then I tried tying the object's transform to the hooks transform in script, so it moves when the hook moves without needing to parent, but then the problem with that was that the object would then would then go through other objects, completely ignoring the collider at some points, or launching other objects or itself into the stratosphere, and there was also the problem of the movement was not looking natural.  

Is there an obvious way to do this that I am missing? 

Thanks in advance!

Hello!
We would like to move a “liquild” bulge along the rope but with a few nuances.


First I’ll describe what we tried. We tried putting a ring-like collider on a rope and moving it along the rope with force. But the ring would get stuck where the rope bends and at places where a particle is attached with ObiParticleAttachment.


We also tried building a level with two ropes and a ball going between them. But it negatively impacted performance and the ball would still get stuck at ParticleAttachments.


We then saw your post where you referenced the hose example (http://obi.virtualmethodstudio.com/forum/thread-2539.html). It could work for us but we can not quite figure out how to hook it up with player input.
Simply put, the bulge should follow the mouse position, but if the player tries to pull the bulge “outside” the rope, doing so should pull the rope (see picture for a graphic explanation).


I assume it could be implemented similar to ObiRopeAttach.cs example. But the question is, is it possible to pull particles in a given direction? Any other advice on the matter would be appreciated too.


Thank you!

Attached Files

Thumbnail(s)
   

So, this time I found that when you delete ropes, it can cause NaNs and absurd velocity assignments to rigidbodies when you destroy a rope's GameObject.

The repro package can be found here: (Expires in 30 days)
https://ufile.io/45i4log9

To reproduce:

1. Start a new Unity project (I'm using 2020.2.0f1).
   
2. Add Burst (version 1.4.8) and Jobs (version 0.8.0-preview.23) through the Package Manager.
   
3. Import the package linked above.
   
4. Open SampleScene.unity and press Play.
   
5. Click and drag to attach a rope. The point where you click (mouse down) will be the first point where a rope gets attached. The point where you let go (mouse up) will be the second point where a rope gets attached. Add several ropes.
   
6. Press [R] to delete all of the ropes you created.
   
7. Repeat 4 and 5 until the bug is reproduced.
   

• The rigidbodies in the scene may start behaving abnormally, with ghost forces pushing them around even though all of the ropes have been removed.
  
• You'll see errors spamming the console regarding invalid forces being applied to one or more of the rigidbodies. For example: rigidbody.velocity assign attempt for 'Floating Platform' is not valid. Input velocity is { 2.468001, NaN, 55.692116 }.
  
• Some of the rigidbodies may explode into outer space from the absurd forces.
  

• When I start SampleScene with a rope in the scene already, (drag ObiPrefabs/Rope into the scene and activate the GameObject before pressing play) any ropes you add to the scene will be frozen and will not simulate.
  
• After reproducing the above bug: When switching to the scene "RopeNet" (which uses a modified example script to use the global solver), pressing play, and then unpressing play, the console will spam about some phantom Obi.ObiLateFixedUpdater trying to poke at various destroyed Obi components. When this occurs, you'll find that there are no ObiLateFixedUpdater instances visible in the hierarchy.
  

• ObiStatic.cs added, which enables a global solver.
  
• ObiStaticSettings.cs added, which allows you to define the global solver using a prefab reference.
  
• When an ObiRope is created, it will check for a solver in one of its ancestors. If one isn't found, it'll use ObiStatic.WorldSolver, which will get instantiated if needed.
  
• RopeNet.cs will use ObiStatic.WorldSolver instead of creating its own solver.