04-02-2018, 08:03 PM
Ah, now that you mention it my question about the chain of tethers was kind of stupid. For some reason I had inferred that tethers work differently from distance constraints which is obviously not the case.
I feel like if there were a direct solver for something like tethers that could be applied after the iterative solver has done its thing, this problem could be solved. All it would do is start at the fixed particle and then move the first particle toward the fixed particle such that the constraint is never violated, then move the 2nd particle toward the first particle and etc. The correction would be minuscule because it would happen every frame so a large deviation could never accumulate. Is there any way to set this up? (Possibly does the api allow direct manipulation of particle positions after the iterative solver runs?)
It's probably a little hacky and I wouldn't suggest it except that I'm really floundering trying to get this to work. When I apply tethers for each particle linked to the fixed particle the rope always wants to fold into a squiggly line and rotate around never settling down. And when I pull the rope (use cursor to reduce the length) it becomes extremely jerky like tugging the rope every few frames instead of pulling it smoothly. I've tried other tether strategies like changing the stiffness, only tethering every nth particle to the fixed particle, and even chaining them together (like tethering the 32nd particle to the 24th, the 28th to the 20th and etc). Nothing seems to give me anything other than a rubber band or a squiggly line that won't shorten with any degree of stability.
I did start by staring at Microsoft's documentation for MoveNext() that you linked to, but like most Microsoft documentation I do not have the intelligence and/or patience to derive any useful information from it. Your one line of code is much more elegant than my solution.
Again for others reading this (although I feel like I may be doing more harm than good with these...) the ObiDistanceConstraintBatch.springIndices has a really interesting structure that's not intuitive; I wrote this function to get the particle index from the position in the rope (particle_number).
private int get_particle_index(int particle_number, ObiDistanceConstraintBatch dbatch) {
if(particle_number == 0) {
return dbatch.springIndices[0];
}
else {
return dbatch.springIndices[particle_number*2-1];
}
}
Thanks,
Jon
I feel like if there were a direct solver for something like tethers that could be applied after the iterative solver has done its thing, this problem could be solved. All it would do is start at the fixed particle and then move the first particle toward the fixed particle such that the constraint is never violated, then move the 2nd particle toward the first particle and etc. The correction would be minuscule because it would happen every frame so a large deviation could never accumulate. Is there any way to set this up? (Possibly does the api allow direct manipulation of particle positions after the iterative solver runs?)
It's probably a little hacky and I wouldn't suggest it except that I'm really floundering trying to get this to work. When I apply tethers for each particle linked to the fixed particle the rope always wants to fold into a squiggly line and rotate around never settling down. And when I pull the rope (use cursor to reduce the length) it becomes extremely jerky like tugging the rope every few frames instead of pulling it smoothly. I've tried other tether strategies like changing the stiffness, only tethering every nth particle to the fixed particle, and even chaining them together (like tethering the 32nd particle to the 24th, the 28th to the 20th and etc). Nothing seems to give me anything other than a rubber band or a squiggly line that won't shorten with any degree of stability.
I did start by staring at Microsoft's documentation for MoveNext() that you linked to, but like most Microsoft documentation I do not have the intelligence and/or patience to derive any useful information from it. Your one line of code is much more elegant than my solution.
Again for others reading this (although I feel like I may be doing more harm than good with these...) the ObiDistanceConstraintBatch.springIndices has a really interesting structure that's not intuitive; I wrote this function to get the particle index from the position in the rope (particle_number).
private int get_particle_index(int particle_number, ObiDistanceConstraintBatch dbatch) {
if(particle_number == 0) {
return dbatch.springIndices[0];
}
else {
return dbatch.springIndices[particle_number*2-1];
}
}
Thanks,
Jon