Solver is too performance heavy

[quent_1982]

Hi,

Your code seems correct to me, assuming the value of the "solverIndex" variable is correct. How are you calculating it? Also, you mention the rope disappears after adding the batch, are you getting any errors in the console as well?

kind regards

No, there is no errors in console, the rope is just disappeared and all joints is become unattached to the rope. SolverIndex variable is correct, I've checked it several times. Also I've tried the code from previous reply with only one batch, and the end of the rope just attached to solverIndex position on the rope - maybe this behavior tells you something.

Kind regads,

[josemendez]

No, there is no errors in console, the rope is just disappeared and all joints is become unattached to the rope. 

Kind regads,

I'm unable to reproduce this behavior. Just tried your code, substituting "solverIndex" with some values in the rope.solverIndices[] array and it works correctly.

Would it be possible for you to share a scene/package that reproduces this problem (by sending it to support(at)virtualmethodstudio.com) so that I can take a closer look?

SolverIndex variable is correct, I've checked it several times.

I asked because assuming the solverIndex variable is indeed the index of a particle in the solver, "solverIndex+1" doesn't make any sense - the solverIndices array might contain *any* particle index values, not just consecutive ones as explained in the manual. So solverIndex+1 is certain to be incorrect. Assuming you want the "next" particle in the rope you should use solverIndices[actorIndex+1] instead.

Also I've tried the code from previous reply with only one batch, and the end of the rope just attached to solverIndex position on the rope - maybe this behavior tells you something.

Your code already only has one batch, with two constraints. Do you mean only one constraint? in that case, which one you omitted to get the rope to attach?

kind regards

[quent_1982]

I'm unable to reproduce this behavior. Just tried your code, substituting "solverIndex" with some values in the rope.solverIndices[] array and it works correctly.

Would it be possible for you to share a scene/package that reproduces this problem (by sending it to support(at)virtualmethodstudio.com) so that I can take a closer look?


I asked because assuming the solverIndex variable is indeed the index of a particle in the solver, "solverIndex+1" doesn't make any sense - the solverIndices array might contain *any* particle index values, not just consecutive ones as explained in the manual. So solverIndex+1 is certain to be incorrect. Assuming you want the "next" particle in the rope you should use solverIndices[actorIndex+1] instead.


Your code already only has one batch, with two constraints. Do you mean only one constraint? in that case, which one you omitted to get the rope to attach?

kind regards

Hello, I attempted to replicate the issue in a test project, but the rope does not disappear. I will send you the test project as soon as I determine what is causing this.

Kind regards.

[quent_1982]

I'm unable to reproduce this behavior. Just tried your code, substituting "solverIndex" with some values in the rope.solverIndices[] array and it works correctly.

Would it be possible for you to share a scene/package that reproduces this problem (by sending it to support(at)virtualmethodstudio.com) so that I can take a closer look?


I asked because assuming the solverIndex variable is indeed the index of a particle in the solver, "solverIndex+1" doesn't make any sense - the solverIndices array might contain *any* particle index values, not just consecutive ones as explained in the manual. So solverIndex+1 is certain to be incorrect. Assuming you want the "next" particle in the rope you should use solverIndices[actorIndex+1] instead.


Your code already only has one batch, with two constraints. Do you mean only one constraint? in that case, which one you omitted to get the rope to attach?

kind regards

Hello, I wanted to follow up and let you know that I sent the test project to you via private message yesterday, please take a look.

Kind regards,

[josemendez]

Hello, I wanted to follow up and let you know that I sent the test project to you via private message yesterday, please take a look.

Kind regards,

Hi!

Thanks, i received the PM. Will test it as soon as I can - probably later today - and get back to you.

kind regards

[josemendez]

Hi,

Took a look at your sample project, but it doesn't make any sense to me.

Current behavior is: as soon as the player grabs the rope, it begings jittering while skidding backwards. This happens because the rope is colliding against the capsule, while attached inside: such a situation is physically impossible to solve situation and should be avoided as explained here).

Swinging with the A and D keys doesn't work since the CustomSwing() method in your CustomGrabbing class doesn't seem to be called anywhere.

There's also many invisible rigidbodies attached to the rope -almost one per particle!- and also attached between them using CharacterJoints. I don't understand the purpose of this: it's as if you're simulating the same rope twice using different engines, and then trying to get both versions to follow each other.

Deleting all rigidbodies (poin1-point20) and ensuring the capsule doesn't collide with the rope fixes the strange behavior.

Note what you seem to be trying to do is very similar to some of the including sample scenes (VineSwinging, specifically). I'd suggest taking a look at them.

let me know if I can be of further help,

kind regards,

[quent_1982]

Hi,

Took a look at your sample project, but it doesn't make any sense to me.

Current behavior is: as soon as the player grabs the rope, it begings jittering while skidding backwards. This happens because the rope is colliding against the capsule, while attached inside: such a situation is physically impossible to solve situation and should be avoided as explained here).

Swinging with the A and D keys doesn't work since the CustomSwing() method in your CustomGrabbing class doesn't seem to be called anywhere.

There's also many invisible rigidbodies attached to the rope -almost one per particle!- and also attached between them using CharacterJoints. I don't understand the purpose of this: it's as if you're simulating the same rope twice using different engines, and then trying to get both versions to follow each other.

Deleting all rigidbodies (poin1-point20) and ensuring the capsule doesn't collide with the rope fixes the strange behavior.

Note what you seem to be trying to do is very similar to some of the including sample scenes (VineSwinging, specifically). I'd suggest taking a look at them.

let me know if I can be of further help,

kind regards,

Hello, thanks for take a look at my test project.

In test project collisions between rope colliders and rope are disabled by setting Collision Category and Collides With on the rope obi colliders.

The invisible rope are needed to find collision point and attach to it and also to generate more stable colliders, the reason for this is that my main character uses convex mesh colliders, and ObiSolver does not work as good as expected.

I've tried to use VineSwinging example and pinholes but it works not good for my main character. The player from example is good to understand what I'm struggling with, so maybe you have any ideas about pinholes or sth that I should implement to get more stable results?

Best regards,

[josemendez]

Hi!

In test project collisions between rope colliders and rope are disabled by setting Collision Category and Collides With on the rope obi colliders.

I don't mean collisions between the rigidbody-based rope and the Obi rope, but collisions between the ObiRope and the character: you're attaching the center of the character to the rope, but the rope is set to collide against the character. This means the engine is simultaneously being asked to keep the rope inside the character (since it's attached to it), and outside of it due to collisions. An object cannot be inside and outside an area at once, so the resulting simulation is not physically meaningful.

The invisible rope are needed to find collision point and attach to it

There is no need to use colliders just to find collision points, Obi already performs its own collision detection that you can get results from and perform queries on:

https://obi.virtualmethodstudio.com/manu...sions.html
https://obi.virtualmethodstudio.com/manu...eries.html

Your current approach doesn't make any sense whatsoever: what's the point of using a particle-based engine such as Obi if you're replicating the exact same simulation using rigidbodies, then attaching the particles in the particle rope to the rigidbodies in the rigidbody rope? why do the exact same work twice?

and also to generate more stable colliders, the reason for this is that my main character uses convex mesh colliders, and ObiSolver does not work as good as expected.

You can use a distance field to get robust collisions against arbitrary shapes, both convex and concave.

I've tried to use VineSwinging example and pinholes but it works not good for my main character.

Could you be more specific about what's not working correctly with your character? Pinholes already implement attaching rigidbodies to a rope and support sliding the attachment point along the rope, so it looks like they're what you should be using in your case.

kind regards

[quent_1982]

Hi!


I don't mean collisions between the rigidbody-based rope and the Obi rope, but collisions between the ObiRope and the character: you're attaching the center of the character to the rope, but the rope is set to collide against the character. This means the engine is simultaneously being asked to keep the rope inside the character (since it's attached to it), and outside of it due to collisions. An object cannot be inside and outside an area at once, so the resulting simulation is not physically meaningful.


There is no need to use colliders just to find collision points, Obi already performs its own collision detection that you can get results from and perform queries on:

https://obi.virtualmethodstudio.com/manu...sions.html
https://obi.virtualmethodstudio.com/manu...eries.html

Your current approach doesn't make any sense whatsoever: what's the point of using a particle-based engine such as Obi if you're replicating the exact same simulation using rigidbodies, then attaching the particles in the particle rope to the rigidbodies in the rigidbody rope? why do the exact same work twice?


You can use a distance field to get robust collisions against arbitrary shapes, both convex and concave.


Could you be more specific about what's not working correctly with your character? Pinholes already implement attaching rigidbodies to a rope and support sliding the attachment point along the rope, so it looks like they're what you should be using in your case.

kind regards

Thanks for mentioned distance fields, I really somehow missed the article about them in docs, I've implement them and all obi collisions are working great now and maybe if I can to implement pinholes I'll be able to completely remove invisible rope and that's great!

But I can not understand how pinholes is working and to what them are attaching to, because when I'm trying to attach some of player's hand or other limb the rope is aiming to reach player's mesh center and as a result there is a big gap between player and rope. By the way, I do not need to climb on pinhole as Vine Example shows, all I need is to grab the rope, swing and reach the rope saving swing impulse.

Best regards,