Hey Virtual Method guys!

I work for an indie studio using Obi Fluid and Rope in the production of one of our current development projects, so far to fantastic effect!

I've been extending the systems provided to match our game's requirements and so far have implemented things like :

- Container Volumes which allow a container to preserve particles within them, to allow the rest of the particles to have a short lifespan to reduce overhead.
- Fluid makeups within containers to cache the percentages of the fluids within a container, adjusting how much is in each etc.
- Leave stains and trails on collision by writing to a render texture with colour matching from the particles.

And quite a bit more - so far this system has been extremely adaptable and truly you guys deserve a lot of credit for a brilliant system!

This next level of optimisation though is something quite important to the performance of our game, so I wanted to ask your opinions before I committed to it for our next milestone.

We do lots of things with collisions, especially with fluid particle collisions, and some of the more intricate containers in our games are made up of quite a few primitive colliders, and so when subscribing to Oni's collision events like so:

Hi!

I have a problem with the ropes. I put some ropes in a crane to move a big panel, as you can see in the video.
When the animation moves the crane up, left or right, the ropes have a good behavior, but when the animation moves the crane down the ropes have a strange behavior, and I don´t know why.

[attachment=346]

This is my solver setup.

[attachment=347]

And my rope setup.

[attachment=348]

Thanks in advance.

Laura.

Hi,

As the title suggests, I've just added a Obi Fluid Renderer to my camera, but it's causing massive black lines to appear between particles that I can't seem to tweak values to remove.

Any ideas?

Thanks.

Hi,

I've recently bought Obi Fluid and I'm making an oil leak. I wanted to know if there was a way to pause the emitter after one complete emission cycle, and have it stay as it was paused until resolved. If not, is there a way I can do this using references from the source code?

Thanks,

Alex.

I'm posting this here in the ObiRope section, because my organization has already purchased ObiRope, and we've been attempting to use it to achieve our desired results with no luck. I'm trying to determine whether or not ObiRope is appropriate for other "strand" uses, that are not rope-like. For example, a very long piece of hair attached to a comb would drag behind the comb as it's moving, much like ropes do with ObiRope when they're hanging from something. However, that same strand of hair would also blow about in any breeze. More specifically to what my team is trying to achieve, is with long sheets of paper. Say in game we're trying to simulate the unraveling of a paper towel roll that was thrown. The issue we're running into is the effect of the end of the roll snapping back towards the roll each time it extends away from the roll. This sort of "snap back"/"bounciness"/"spring" effect isn't accurate to paper as it is to a rope. Is there any way we can disable this affect?


If not, would ObiCloth be better suited to our needs? Meaning, could the simulation of paper unraveling from, and flowing behind an airborne roll of paper towel being achieved?

Thanks in advance!

When I created a fully setup soft body, everything works well. If I change the mesh scale and particle setting, the simulation looks good but sometimes the skin mesh disappear (seems like crashed). The same thing also happened when I changed the mesh object. I did initialize  the particle generation everytime I changed something. However, it still happens. How to solve this problem ? For now, I have to delete the whole soft body object and remember all the parameters. Then create a new softbody using the parameters. Then it works.

What is the difference between the renderablePositions and position in ObiSolver

Hello,

We have an application that uses Nvidia Flex particle system. We wanted to check if there has been any interaction testing between Nvidia Flex (Cloth) and Obi Fluid. We're coming up with some restrictions for fluid options within Flex-only so we wanted to investigate other solutions for our fluid needs. 

Thanks!

Hello,

I recently updated my project to both ObiCloth 4.1 and Unity 2018.3.

My project uses prefabs, nested prefabs and prefab variants. Whilst working with ObiCloth I have encountered a few issues regarding Obi Pins and Obi Handles.

Defining Pin constraints in the Prefab editor simply does not work. References to the Pin object are not preserved. I am forced to unpack the Prefab, modify the ObiCloth, and re-create the Prefab. 

I've noticed a similar problem with Obi Handles, they do not a appear in the hierarchy when creating them.

I think the issue may be in part due to how the Prefab system recognizes objects as 'changed', as modifying many of the ObiCloth attributes does not appear to result in a 'dirtying' of the object, which may be causing some issue elsewhere?

Any support on this would be greatly appreciated.

Thanks in advance. Really impressed with the continued support and enhancement of this fantastic asset!

Hello.

We're using Obi Cloth in our VR app. There are two pieces of cloth that the user must grab and drop on the floor. So we must check if the controller is within range of a particle to grab the cloth, and if majority of the particles are on the floor.

Previously, we were checking the position of the particles by doing actor.GetParticlePositions().

If I understand correctly, that returns renderable positions, and only works appropriately if you tell the solver of the actor to RequireRenderablePositions? Otherwise those renderable positions don't move if the cloth moves. Then you can call RelinquishRenderablePositions when you're done, and the main reason for that is that renderable positions are a little expensive?

I also discovered an alternative way to do this by calling actor.PullDataFromSolver(ParticleData.POSITIONS), then the actor has a vector3 positions array of all the particles. The documentation referred to this as "normal positions".

Three questions:

1. Is that more or less expensive than doing renderable positions?
   
2. If it's less expensive, how often do you have to call PullDataFromSolver()? Every frame?
   
3. And am I on the right track here, or is there a better way we should be checking the position of the particles?