I try to detect and display an intersection between a SPS and an mesh. My particles are created from a digested mesh.I can detect the intersection and change the color of the particles but it do not appear when I expect. The particles colors are changed hen the mesh is no longer in intersection with the particles. Below is a playground.
Well, either the issue is in the digest process, or in the Bbox computation (or both), or in something regarding the local/world spaces. Not sure…
It looks like a local/world spaces issue from what we can see.
Thanks a lot to take into consideration my question.
I used the vertex baking in order to have the particles of the digested mesh in the right position after scaling the model mesh. Without it, the SPS.digest(model) use the model without scaling, rotating modifications.
I guess I have a lead.
When digesting a mesh into a SPS, as this SPS has no idea about the mesh geometry, each particle is built according to the initial mesh facet vertex positions. Said differently, if I remember correctly, each particle vertex has the same fpositions than the facet vertex pool it describes. This means that all the particles of a digested mesh have all their positions (and rotations) set to zero but are translated and rotated in their own local space, a bit like you would bake the vertices of a mesh after some transformation.
So the particles of a digested mesh aren’t centered in their own local space but have actually a position (and rotation) set to zero in the SPS local space.
Well, actually, it’s not technically a bug but probably more a missing feature… like to optionnally force a digested SPS to transform its particles from “baked” ones at the origin to locally centered ones (barycenter ? no idea about the rotation to apply then) with each its own valued position in the SPS local space.
The sphere touches all side facets but only two facets are changed on intersection. Perhaps something to work with when testing! You will need to rotate the camera.
the second reason I can see is that using planar particles (facetNumber = 2 -> quads), their bounding boxes will be quite weird to check in the intersection test.
well, so there’s something wrong and buggy in the digested SPS regarding the Bbox computations…
In a digested SPS, the particles aren’t (usually) centered around their positions. This means that the Bbox can be located quite far from the actual particle position (meaning the value of the property position )
You show me a successful complex system, and I will show you a system that has evolved through trial and error.
Accepting trial and error means accepting error. It means taking problems in our stride when a decision doesn’t work out, whether through luck or misjudgment. And that is not something human brains seem to be able to do without a struggle.
Success Comes Through Rapidly Fixing our Mistakes Rather than Getting Things Right the First Time.
So it seems that all I explained before is wrong : the particles from a digested SPS are actually already positioned to their barycenter position (so position not equal to zero)
This is a good news (even if this was coded years ago actually) because this will bring the same particle behavior than the one of standard (not digested) SPS. My brain was better than I now think at this time
There’s still an issue about the Bbox then. As I can’t remember how the BInfo creation really work, I suppose that the error could be at this line (no way for me to code or check for the moment) :
when passing the barycenter as a parameter to the BInfo constructor.
In brief, it looks like that, contrary to what I explained formerly, the digested SPS particles are built and behave just like the ones of a standard SPS in terms of particle initial positioning.
There’s certainly a bug in a the way their BInfo are initialized.
[EDIT] it should be the minimum and maximum vectors instead. They aren’t stored when computing the barycenter.
probably something like this to compute when iterating over each shape vertex within the barycenter computation :
minimum.minimizeInPlaceFromFloats(px, py, pz);
maximum.maximizeInPlaceFromFloats(px, py, pz);
[EDIT 2] I’m still convinced that planar particles (or meshes) could lead to weird Bbox computations in intersection tests
Glad you contacted @sebavan as I have been looking at the problem and think the changes needed are
// shift the shape from its barycenter to the origin
// calculate minimum and maximum vectors
var minimum: Vector3 = new Vector3(Infinity, Infinity, Infinity);
var maximum: Vector3 = new Vector3(-Infinity, -Infinity, -Infinity);
for (v = 0; v < shape.length; v++) {
shape[v].subtractInPlace(barycenter);
minimum.minimizeInPlaceFromFloats(shape[v].x, shape[v].y, shape[v].z);
maximum.maximizeInPlaceFromFloats(shape[v].x, shape[v].y, shape[v].z);
}
var bInfo;
if (this._particlesIntersect) {
bInfo = new BoundingInfo(minimum, maximum);
}
However I am in the middle of working on PointCloud particle system (still - as I got in a muddle trying to adapt SPS and realised that I needed to think about what was needed and start from there) and so have uncommitable code (and I don’t know how to set it to one side while trying out changes to other scripts)
I just can’t retrieve the very old history of the file SolidParticleSystem.ts to check why I would have coded such a weird thing like “new BoudingInfo(barycenter, barycenter)”. No matter …
