MultiMaterial with 2 materials kills SolidParticleSystem

Bugs
1

Hi all!

When porting my flightsim from 4.2.1 to 5 I ran into a couple of issues. Here is one:

When running a SolidParticleSystem with 2 models and 2 materials, all particles vanish on certain camera positions.

Look at this for a while: Bug: SPS MultiMaterials stops rendering particles | Babylon.js Playground (babylonjs.com)

Maybe not related, but the effect with the second material is the same as if computeBoundingBox is not set (also in 4.2.1).
I never understood why setting this flag is mandatory even in 4.2.1.

2

Hello! Going to take a look.

It’s not mandatory, just computing the bounding boxes is off by default to save on performance, so the entire system’s bounding box is taken as the first particle bounding box when the compute doesn’t happen.

For cases where the particles are expected to always be on camera that is enough, but for cases where the particles vanish from camera then either the bounding box will have to be computed or the mesh will have to always be active.

3

See Troubleshooting Solid Particle System Visibility Issues | Babylon.js Documentation

4

That’s an excellent link, thank you. I wish I saw it earlier. Although it contradicts @carolhmj 's description.

Using isAlwaysVisible can solve my particular issue.

Still doesn’t explain the MultiMaterial thing.

5

Sorry, can you elaborate more on the contradiction part? Just want to check if my understanding is following the documentation.

About the multimaterials, we also need to set the autoUpdateSubMeshes flag as true, because a SPS with multi materials uses submeshes to draw them. I’ll update the docs to include that too.

6

Updated docs: Update SPS visibility docs. by carolhmj · Pull Request #625 · BabylonJS/Documentation (github.com)

1 Like
7

The former doc read like this:

So the size of the SPS mesh is initially the size of its biggest particle, so it is for its BBox.

‘entire system’ vs. ‘biggest particle’ sounded like a contradiction to me.

1 Like
8

Still, that fact that the SPS’s visibility depends on whether 2 particle meshes use the same or different materials seems like a bug to me.

At least that changed since 4.2.1 (that’s the reason why I ran into that, bc. my particles were all gone).

If it’s not, it’s not :slight_smile:

9

At least my flightsim flies again as in 4.2.1 :slight_smile:

Thanks alot!

10

@carolhmj could you check what changed ? as it could feel like a regression and I wonder why the behavior changed ?

11

I don’t understand exactly, what you mean. My app got healed by applying isAlwaysVisible instead of computeBoundingBox, which clearly is the better choice for my specific case.

The regression can be seen in the PG I provided (where computeBoundingBox is still used).

v4.2.1:

  • 2 models, 1 material: SPS is always visible
  • 2 models, 2 materials: SPS is always visible

v5:

  • 2 models, 1 material: SPS is always visible
  • 2 models, 2 materials: SPS vanishes

So in 4.2.1, materials and visibility are not related, in 5 they are.

13

I’ll take a look, I wonder if SPS with multimaterials didn’t generate submeshes before :thinking:

14

Nope, the submeshes were always there, but I pinpointed version 5.6.1 as the one where the behavior changed. Looking at the changelog, this: Fix SubMesh IsGlobal by BlakeOne · Pull Request #12529 · BabylonJS/Babylon.js (github.com) is the only change related to submeshes, so my guess is that, before it, the SPS submeshes were returning the entire SPS’s bounding box and so weren’t culled out?

15

nice so the fix from blake looks all right !!!

1 Like
17

@carolhmj
So it isn’t a regression? Shouldn’t computeBoundingBox affect all submeshes in a SPS?
Although I’m not sure whether I understand the fix at all.

Is computeBoundingBox worth anything if it depends on the number of materials?

18

Nope, what was happening before is that the SPS particles were always returning the entire SPS’s bounding box as their own bounding box, which was not correct behavior. Blake’s fix made it so that the particle’s bounding box is the size of just the particle. computeBoundingBox doesn’t affect the submeshes because a SPS might not have submeshes, that only happens when you want multiple materials.

19

Call me stupid, but in case I have a 2model/2material SPS, how can I keep it visible other than using isAlwaysVisible?

That’s what happened in my app when migrating to v5 even using computeBoundingBox. The SPS when out of bounds and nothing was seen any more (I wasn’t aware of isAlwaysVisible those days).

20

Asking questions and trying to understand how things work is never stupid :stuck_out_tongue: You just need to set the autoUpdateSubmeshes flag to true too! Using it or isAlwaysVisible will depend on your use case, since isAlwaysVisible doesn’t compute the bounding box and always draws everything, it will be easier on the CPU but harder on the GPU.