09-09-2020, 12:47 PM
(This post was last modified: 09-09-2020, 01:47 PM by josemendez.)
Hi there,
Non-uniform scales on deformable objects do not make much sense, mathematically speaking. You can't describe the shape/position/orientation of a non-rigid object using a single transform matrix. It's better to stick to unit scaling when dealing with deformables (not just in Obi).
Regarding collision indices, I believe the manual holds the answer
http://obi.virtualmethodstudio.com/tutor...icles.html
Then it follows with some examples of converting actor particle indices to solver particle indices and vice-versa.
The solver does not know what an "actor" is, all it knows about is a literal list of particles. So when you add the first actor -lets say a rope with 20 particles-, particles 0 to 19 in the solver array are assigned to it. When you add the second actor, again with 20 particles, the solver will assign particles 20 to 39. This is very similar to how a simple memory allocator works. When removing actors, gaps might appear in the solver particle array, then later reassigned to new actors that have their particles spread all over the solver. So, in general you can't assume actor indices == solver indices.
If there's a collision between say, the third particle in the first rope and the fifth particle in the second rope, the solver will report a contact between particle indices 2 and 24.
Because ropes can be torn and resized, they preallocate more particles than initially visible. By default the size of this particle pool is 100 (you can control this in the blueprint inspector). So your second rope will have particle indices starting at 120, because the first rope has 18+1+100 = 119 particles. This is why you can't do:
You must iterate over elements and find the one such that element.particle1 == args.contacts[i].particle, as I pointed out before.
Non-uniform scales on deformable objects do not make much sense, mathematically speaking. You can't describe the shape/position/orientation of a non-rigid object using a single transform matrix. It's better to stick to unit scaling when dealing with deformables (not just in Obi).
Regarding collision indices, I believe the manual holds the answer
http://obi.virtualmethodstudio.com/tutor...icles.html
Quote:Actor particle indices run from 0 to the amount of particles in that actor. However, since particle data for an actor might be scattered across the solver arrays (see architecture), you need to map from actor index to solver index. You can map from actor particle indices to solver particle indices using the actor's solverIndices array.
Then it follows with some examples of converting actor particle indices to solver particle indices and vice-versa.
The solver does not know what an "actor" is, all it knows about is a literal list of particles. So when you add the first actor -lets say a rope with 20 particles-, particles 0 to 19 in the solver array are assigned to it. When you add the second actor, again with 20 particles, the solver will assign particles 20 to 39. This is very similar to how a simple memory allocator works. When removing actors, gaps might appear in the solver particle array, then later reassigned to new actors that have their particles spread all over the solver. So, in general you can't assume actor indices == solver indices.
If there's a collision between say, the third particle in the first rope and the fifth particle in the second rope, the solver will report a contact between particle indices 2 and 24.
Because ropes can be torn and resized, they preallocate more particles than initially visible. By default the size of this particle pool is 100 (you can control this in the blueprint inspector). So your second rope will have particle indices starting at 120, because the first rope has 18+1+100 = 119 particles. This is why you can't do:
Code:
selectedRope.elements[args.contacts[i].particle]You must iterate over elements and find the one such that element.particle1 == args.contacts[i].particle, as I pointed out before.