25-01-2018, 12:42 PM
[quote pid='1010' dateline='1516871445']
[/quote]
Unfortunately, the part about constraint enforcement order is simply not true, at least not from my testing. For instance, i have a case where i want a rope to stay tense when attached between a series of points, but despite having the distance constraint solver last, with 15 iterations, and having the slack/stretching scales set to extremes, i still can't get it to tensen. I f i set the SOR factor to 1.5, it gets closer, but the whole cord starts to twitch and spin. Here is a picture of what i mean:
[attachment=67]
Setting the pin constraint last seems to work for simple two-ended ropes, but if you make something more complex there are no guarantees, especially not when working with VR where very large forces may be applied in order to force the object into your hand.
My wall setup looks like this:
[attachment=68]
Basically, it is a rigidbody for each plug, with kinematic ObiRigidbodies and configurable joints with distance limits to tie them together. The top plug is attached into the air with a fixed joint with no target. The wall has an ObiCollider. It starts off all and well, and usually has time to comes to rest, but sooner or later it will cause a crash - often when one of the plugs collide with the wall (for instance if you grab one and drop it like a pendulum). The cord otherwise works fine if you're just holding it in your hand.
I tried implementing the same cord multiple times with Obi constraints, but it just becomes too springy and never comes fully to rest. There are other somewhat infuriating aspects of working with ObiRopes which makes me want to stick to regular joints, like the fact that ropes inside a prefab will revert all non-applied changes when you press play, and the fact that you have to re-initialize the rope, thus being forced to re-do all the pin constraints, whenever you want to adjust the curve... i've been trying to make this work since September last year and the moment i accepted the compromise of using configurable joints, everything started acting much more like i wanted. Sorry if i come across as rude, i really do think this is a good product (especially for the price), and i appreciate your support, so far i've tried three different physics engines and this is the one which produces the most stable results. Still, it responds very poorly to the way you configure it.
josemendez Wrote:Change constraint enforcement order, so that pin constraints are resolved last. See the last bit of:
http://obi.virtualmethodstudio.com/tutor...olver.html
You can reduce the timestep in Unity's time settings. This will cause the simulation to take smaller temporal steps, and will be much more effective than increasing iteration count.
As pointed out the gap is not a result of convergence issues, but constraint application order. By default pin constraints are applied before distance constraints, which makes the latter prevalent in the final result. Reversing the order gives priority to pin constraints and closes the gap since pin constraints are applied last and their actions are not "undone" by distance constraints.
This cannot be worked around as it is a result of how iterative physics solvers work: more resolution->more constraints->slower convergence->less bending resistance. You can increase the amount of bending constraints to compensate the higher resolution, though.
Objects that are marked as kinematicForParticles will cause the rope to be unable to perform two-way interaction with them, effectively making ropes "passive", which is something I don't think you want.
I will take a deeper look at the crash, but a first quick look suggests a energy feedback loop somewhere. This would cause a rigidbody to store up energy and "launch" itself incredibly far and fast. This is typical of local-space simulations being performed on the local space of a rigidbody that is in turn affected by the simulation, as this causes the reference frame for the sim to change as a result of the simulation itself. Having a deeper understanding of your hanging wall rope setup would help a lot though, as this can be very hard to reproduce.
Keep in mind that every vertex in every rope is being recalculated from scratch every frame, plus normals, tangents and uvs, after being smoothed out using bezier splines. Depending on your rope "smoothness" parameter this can be a lot of work. Try switching to line rendering mode and see if that helps, that will reduce the poly count a lot. You can still use normal maps to make a line-rendered rope look 3D.
Here's a manual page on particle scripting:
http://obi.virtualmethodstudio.com/tutor...icles.html
Another one on collision callbacks in case you need them:
http://obi.virtualmethodstudio.com/tutor...sions.html
[/quote]
Unfortunately, the part about constraint enforcement order is simply not true, at least not from my testing. For instance, i have a case where i want a rope to stay tense when attached between a series of points, but despite having the distance constraint solver last, with 15 iterations, and having the slack/stretching scales set to extremes, i still can't get it to tensen. I f i set the SOR factor to 1.5, it gets closer, but the whole cord starts to twitch and spin. Here is a picture of what i mean:
[attachment=67]
Setting the pin constraint last seems to work for simple two-ended ropes, but if you make something more complex there are no guarantees, especially not when working with VR where very large forces may be applied in order to force the object into your hand.
My wall setup looks like this:
[attachment=68]
Basically, it is a rigidbody for each plug, with kinematic ObiRigidbodies and configurable joints with distance limits to tie them together. The top plug is attached into the air with a fixed joint with no target. The wall has an ObiCollider. It starts off all and well, and usually has time to comes to rest, but sooner or later it will cause a crash - often when one of the plugs collide with the wall (for instance if you grab one and drop it like a pendulum). The cord otherwise works fine if you're just holding it in your hand.
I tried implementing the same cord multiple times with Obi constraints, but it just becomes too springy and never comes fully to rest. There are other somewhat infuriating aspects of working with ObiRopes which makes me want to stick to regular joints, like the fact that ropes inside a prefab will revert all non-applied changes when you press play, and the fact that you have to re-initialize the rope, thus being forced to re-do all the pin constraints, whenever you want to adjust the curve... i've been trying to make this work since September last year and the moment i accepted the compromise of using configurable joints, everything started acting much more like i wanted. Sorry if i come across as rude, i really do think this is a good product (especially for the price), and i appreciate your support, so far i've tried three different physics engines and this is the one which produces the most stable results. Still, it responds very poorly to the way you configure it.