Suggestion / Idea Ladder made by Ropes (Ratlines)

[jaripam]

Hey,

Before I dive deeper into this, I was hoping to get some general advice on how to approach my problem.

I'm trying to create ratlines, the rope ladders found on ships, something like this:


https://www.cgtrader.com/3d-models/vehic...on-ship-n1

I want to add some life to these ropes, also characters should climb up/down.

Would it be advisable to use Obi Rope for this kind of rope setup?
Ideally, I’d like the ropes to be separate, since they might tear apart during gameplay. If not suitable, maybe you have an idea what I can do.

Thanks a lot!

[josemendez]

Hi,

You can use ObiRope to do this, but be warned that it's an extremely complex task and it involves a lot more than just the ropes. I wouldn't attempt to tackle it unless you're intimately familiar with physics simulation, IK, procedural animation, character controllers, and the way they interact with each other and game logic. Certainly not a casual feature to add to your game.

Performance considerations are also important, since the amount of ropes and the complexity of their interactions is rather high.

Depending on how you plan your character controller to work and what kind of animation system you'd like to set up, the way you'd implement this varies considerably. I'd be able to help given more details about your use case.

kind regards,

[jaripam]

Hey, thanks!

What I intend to do is to have these ladders (and other ropes) to not be static but rather to move realistically with the wind and when characters climb.

I have some years of Unity experience and also I could build the character controller from scratch around this feature.
However, I don't want to go down a rabbit hole where I have to hack in lots of edge-cases and make the whole thing unstable (if I can avoid it). 

So how exactly I approach this, is fully open atm.
 
Maybe an idea, if I make the full ladder as a single mesh instead of multiple single ropes?
Would this work with the other features like tearing and interaction?

I'd prefer a more realistic solution with multiple ropes but if you think the workload would be exponentially higher, I'd rather skip that.
Or if you have any other rough ideas, please let me know



josemendez
Hi,

You can use ObiRope to do this, but be warned that it's an extremely complex task and it involves a lot more than just the ropes. I wouldn't attempt to tackle it unless you're intimately familiar with physics simulation, IK, procedural animation, character controllers, and the way they interact with each other and game logic. Certainly not a casual feature to add to your game.

Performance considerations are also important, since the amount of ropes and the complexity of their interactions is rather high.

Depending on how you plan your character controller to work and what kind of animation system you'd like to set up, the way you'd implement this varies considerably. I'd be able to help given more details about your use case.

kind regards,

[josemendez]

Maybe an idea, if I make the full ladder as a single mesh instead of multiple single ropes?
Would this work with the other features like tearing and interaction?

Rendering and physics are completely orthogonal to each other: how you render the ladder has *zero* impact on physics simulation. All ropes managed by a solver are already automatically batched together (as long as they share the same material) and rendered as a single mesh for performance reasons.

If you had in mind a single flat mesh for the entire ladder with a texture on it (kinda like cloth, more than a net), that could work in case you want very low-quality approximation. But in this case, ObiCloth would be a better fit.

I'd prefer a more realistic solution with multiple ropes but if you think the workload would be exponentially higher, I'd rather skip that.
Or if you have any other rough ideas, please let me know

The number of ropes doesn't matter in terms of performance either. What matters is the number of particles used to represent the rope (or ropes), and how often the simulation is updated: spatial and temporal resolution, respectively.

So 1 rope made of 1000 particles and 10 ropes made of 100 particles each have the exact same cost. Depending on how you want the character to interact with the ladder, and how realistic you want rope-rope interactions to be, you'd need a finer or a coarser representation of the ladder.

At a minimum, you'll need one particle per rope intersection in the ladder. Then I'd add one extra particle at each "square edge" so that the ropes are at least able to droop a bit. Then depending on how fine/detailed you want the simulation to be, and how you want to handle character interaction with the ropes (each limb has IK towards the closest particle and hands/feet get constrained to the particles is the first thing than comes to mind) you may go for a more detailed representation.

kind regards,

[jaripam]

Rendering and physics are completely orthogonal to each other: how you render the ladder has *zero* impact on physics simulation. All ropes managed by a solver are already automatically batched together (as long as they share the same material) and rendered as a single mesh for performance reasons.

If you had in mind a single flat mesh for the entire ladder with a texture on it (kinda like cloth, more than a net), that could work in case you want very low-quality approximation. But in this case, ObiCloth would be a better fit.


The number of ropes doesn't matter in terms of performance either. What matters is the number of particles used to represent the rope (or ropes), and how often the simulation is updated: spatial and temporal resolution, respectively.

So 1 rope made of 1000 particles and 10 ropes made of 100 particles each have the exact same cost. Depending on how you want the character to interact with the ladder, and how realistic you want rope-rope interactions to be, you'd need a finer or a coarser representation of the ladder.

At a minimum, you'll need one particle per rope intersection in the ladder. Then I'd add one extra particle at each "square edge" so that the ropes are at least able to droop a bit. Then depending on how fine/detailed you want the simulation to be, and how you want to handle character interaction with the ropes (each limb has IK towards the closest particle and hands/feet get constrained to the particles is the first thing than comes to mind) you may go for a more detailed representation.

kind regards,

That's helpful, thanks. I will give it a shot.

One follow up question I have: 
Is there some kind of integrated LOD system or any other way you can think of to fade in/out the ropes?  
Would it make sense anyway if I use the compute (GPU) option (I guess the GPU cost also increases linearly with the particle amount)?

[josemendez]

One follow up question I have: 
Is there some kind of integrated LOD system or any other way you can think of to fade in/out the ropes? 

Physics systems often don't have LOD, because it would affect gameplay: for instance, if you were to use less substeps or less particles for distant ropes, rope behavior would be slightly different and that would mean the character would also react differently to it depending on distance to the camera. That's something you'd usually want to avoid if you're after consistent results.

Rendering-wise, LOD can happen either by using simpler meshes, simpler shaders, or both. Obi allows you to decimate and/or smooth rope meshes, you can use this to generate lower-resolution meshes for distant ropes without affecting physical behavior.
 

Would it make sense anyway if I use the compute (GPU) option

Not in your case. The baseline cost of GPU simulation is higher than a CPU one, and it only makes sense to use it if your simulation is really large (+5000 particles or so). Plus your character controller works in the CPU, so it doesn't really make sense to process physics on the GPU to then have to copy data back to the CPU. See:
https://obi.virtualmethodstudio.com/manu...kends.html

(I guess the GPU cost also increases linearly with the particle amount)?

It increases linearly with particle amount, but the slope of the cost vs workload line is a lot less pronounced than CPU.

kind regards,