Intersection between a SPS from au digested mesh and a mesh

Hi All,

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.

I would like the particles to color in red when there is an intersection with the mesh.

Thank you very much if you have an explanation to this behavior.

Hello and welcome to the forum, adding @jerome our SPS guru :slight_smile:

weird …
I just refreshed the bounding info of each mesh :
It looks like there’s some shift between local/world coordinates.

Actually, the SPS intersections are designed to work in the SPS local space only : Use the Solid Particle System - Babylon.js Documentation
Babylon.js Playground

but I can’t see here why it doesn’t work … something related to the initial vertex baking ? not sure

same with no vertex baking :
still not working as expected …

[EDIT] same thing when setting the intersection test within the call to updateParticles() :

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.

Or anything else I can’t see yet

not related to the cylinder geometry either :

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.

Thanks again for your time.

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.

[EDIT] I really think it’s the cause, because it works as we could expect with a non-digested mesh SPS

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.

1 Like

I have produced a simplified example Babylon.js Playground

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.

But there’s still an issue with the particle Bboxes of digested SPS :
not sure …

I am definetly convinced that using planar particles leads to a wrong Bbox computation anyway

it works well with 4 facets (so 3D) :
not well with 3 facets (maybe some remain planar then) :

With 4 facets and the sphere well away from the mesh the colors say it intersects

Interestingly moving particles hitting a sphere seems to work for all faces

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 )

I guess the issue is related to this fact.


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.

1 Like

What is funny (what I find funny) is that I actually already coded the barycenter sutff : Babylon.js/solidParticleSystem.ts at master · BabylonJS/Babylon.js · GitHub

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 :smile:

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

I’ve just explained to @sebavan where the bug could be as I can’t fix it here (no dev platform).

1 Like

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++) {
                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)


Works like a charm doing the PR in 2 minutes :slight_smile:

Thanks both @jerome and @JohnK, I just had to copy paste the code.


Fix SPS intersection and BBox computation by sebavan · Pull Request #6762 · BabylonJS/Babylon.js · GitHub this will be in the next nightly.


Nice collaborative work @JohnK and @sebavan
Thank you

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 …