I think I found a bug on ParticleEmitter

I have an scene with an object that will be updated to BoundingSphere, if I try to add particles in the scene management, when it runs, it gets the follow error :

java.lang.ClassCastException: com.jme3.bounding.BoundingSphere cannot be cast to com.jme3.bounding.BoundingBox
at com.jme3.effect.ParticleEmitter.updateParticleState(ParticleEmitter.java:1021)

This is the line :

    BoundingBox bbox = (BoundingBox) this.getMesh().getBound();
    bbox.setMinMax(min, max);

It seems particlemanager is trying to update the size of the spatial shape, and if its not an box shape it bugs.

It would be nice to have an option to not update the shape to fill the particles if you dont want (I guess almost every case).

I believe you are aware what ClassCastException means. You said you updated bounding volume to BoundingSphere. Then in your code you cast to BoundingBox.
Instead do:

BoundingSphere bsphere = (BoundingSphere) this.getMesh().getBound();

It’s not his code… it’s JME code that expects its own created class to use its own created field values of a particular type.

Particle Emitter updates the bounding shape automatically so that the particles aren’t culled from the view frustum.

Its not my code, its an bug in the Jm3 core java.
That is what I am showing here.
I dont know how to fix or colaborate to fix bugs in jm3 core, but if someone is colaborate and could look at this bug it would be nice.

Could you please provide a test case?

I see. I missed that part.

I’ve checked the ParticleEmitter implementation. It quite heavily depends on BoundingBox.

However, I wonder, would it be useful to support different bounding volumes for ParticleEmmiter.

Because if you attach it in the scene management it changes the bounding shape of the entire scene object, also changes the center of mass point.
I think an option to disable it would be nice, I dont mind if it will be culled in most cases.

Test case :

public void simpleInitApp() {
    Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
    Spatial spatial  = assetManager.loadModel("Models/emptyScene.j3o");

    Box b = new Box(1, 1, 1);
    Spatial geom = new Geometry("Box", b);
    mat.setColor("Color", ColorRGBA.Blue);

    ParticleEmitter emit = new ParticleEmitter("Emitter", Type.Triangle, 300);



    BoundingSphere boundingSphere = new BoundingSphere();

An bether way to test it should be creating an new scene using some objects imported from blender, add an particle into it, then in the code update the modelbound.

The other side of the issue here is that node.setModelBound() pushes that bounding shape to all of the children. To me, that was kind of a questionable design choice. Had it simply overridden the calculated one in the local node then this wouldn’t have been an issue.

Let’s change this then.

The ParticleEmitter class is highly dependent on the bounding volume being a BoundingBox … Normally you wouldn’t need to change this.

I disagree, if you use any different bounding shape it make it bugged.
Its not uncommon to use sphere shapes or custom shapes.
The only reason why this is not an big issue its because its easy to workarround, but its still an issue.

To give you an example, in my case I was trying to put engine smoke particles in an spaceship, and it has sphere shape… Using the editor get it buged…

There is one of two bugs here:

  1. JME pushes a set bounding shape down to all children.
  2. JME doesn’t accept different shapes for Particle Emitter. (and implies fixing everywhere else we expect a specific bounding shape also, see below)

Only one of those should be fixed.

In the case of (1), if we don’t fix that then it logically leads to 2. Because if we are going to force bounding shapes on random child geometry just because it’s set on a parent then we should always accept any kind of bounding shape in JME code… (ie: particle emitter)

However, to me that makes no sense. Some children will have their own bounding shapes and should not accept others… whether they are statically known because of certain kinds of content (terrain, simple shapes, etc.) or because they are calculated at runtime (like in particle emitter)

I can’t figure out what the down side of fixing (1) is.

Fixing (2) could be problematic and at the very least makes particle emitter kind of wimpy in that it completely cuts off its ability to self-calculate bounds when a different shape is set. To me this should only be considered if there is some hidden gotcha to fixing (1).

I think there is no need to do bug 2 if we fix bug 1, I mean, particle emitter may work fine only using boundingbox, the problem relies on the parents being changed by it.
What is the issue if we just disable this ( item 1) ?

Yes, that’s why I mentioned that they were mutually exclusive twice. :smile:

Fix (1) and you don’t have to fix (2). Don’t fix (1) and you have to fix (2) and probably a bunch of other edge cases.

I also prefer (1).