JME3 ParticleEmitter attached to the guiNode is not visible?

I am creating a 2D-looking game and I would like to add some particle emmiters there. However, when I attach a particle emitter to the guiNode, the emitter is not visible, but it is very well visible being attached to the rootNode. There is no need in a code sample of my project because the most basic case described in the canonical JME3 tutorial behaves the same way. I have checked and I am sure that coordinates and sizes are correct for the effect to be visible on screen - apparently there is some other reason on why doesn’t it show.

I have found an old thread with the same question ( Particle Emitter on guiNode ) - the most probable answer there is that the emitter is essentially 3D and can’t be displayed in 2D which does not seem like the real cause because all other things are just 2D simulated with 3D. So the questions are - why isn’t the emitter visible? Is there an easy way to make it visible with standard out-of-the-box JME3 library?

The gui node (as the name indicates) is for 2D gui elements. If you want the emitter to be visible in the camera at all times move it with the camera.

2 Likes

So, you mean I have to either:

  1. attach the emitter ot the root node, project the desired 2D on-screen position into 3D space, reposition the emitter in 3D there on every update? how do I deal with z-order then…?
  2. write a 2D particle emitter - seems like a more sensible option

The issue is the scale.
The root node Unit is a World unit, the GUI node unit is a pixel.
Default particle emitter particle start size is 0.2. Meaning 0.2 pixel in the gui node.
Scale it by 100 and you should see it.

1 Like

Seems like it is not about scale. Initially I set the start and end sizes to 15 and 20 - that should make the particles visible (while the emitter is attached to the rootNode, the particles are very big, crowding the whole screen). However, I have found one of your recent posts here: Can you use the guiNode to create a 2D game? and it looks like I have to move along that line - taking all my game to the rootNode, setting the viewport projection to parallel.

EDIT: just as a side note, I have been looking into all the related questions on making 2D with JME3… I think it worth having a tutorial on how to make a fully capable 2D game with it. Still, after spending so much time with 2D projects I am not even sure that I get all things correctly - for example, this unexpected issue with the emitter…

The guiNode is in the GUI bucket which flattens Z… basically there is no depth buffer. Pixels are drawn in exactly the order rendered… and the objects are rendered back to front. It technically can be used for purely 2D scenes but I think it will have nothing but issues for 2.5 D scenes (scenes that are 3D but all objects are on a single plane) because even a single object can render badly without depth buffering.

The right solution for 2.5 games is to create another viewport and use parallel projection. Then you can set the scale to whatever you want when you set the camera up and it will otherwise be just like a 3D scene, with proper depth buffering, opaque and transparent buckets, etc.

1 Like

I got it. Now having some success with a custom viewport and camera. However, there is one thing I do not fully grasp: how do I setup frustum for such a view correctly? Looks like for guiNode, the Gui bucket does all the magic, and there is no way to see how do I setup a proper projection myself. Currently, trying to figure out the correct frustum I always get my objects somewhat misplaced and projected inconsistently on the screen… I beilieve it is about frustum setup. I have taken the setup from the TestParallelProjection sample:

    private float frustumSize = 1;

    // Setup first view
    cam.setParallelProjection(true);
    float aspect = (float) cam.getWidth() / cam.getHeight();
    cam.setFrustum(-1000, 1000, -aspect * frustumSize, aspect * frustumSize, frustumSize, -frustumSize);

but frustumSize being equal to 1 gives a too zoomed-in picture… are there any guidelines for defining the frustum correctly?

What happens when you use a frustum size of app.getCamera().getHeight() * 0.5f?

…I’d think something like that will give you 1:1 mapping between pixels and units but I’ve never done it.

1 Like

That worked! Thank you very much, the magic is the numbers! However, one more thing: as the root node for the viewport is located at the centre of the screen, all gets translated +width/2, +height/2… is there a way to correct that with projection instead of geometry positioning?

rootNode.setLocalTranslation(-cam.getWidth() * 0.5f, -cam.getHeight() * 0.5f, 0)?

Edit: actually even moving your ortho camera probably works… I’d originally assumed you’d already tried it but it’s bad to assume.

I also had issue with particle emitter in the GUI node. It just didn’t work, so I took particle material and removed bunch of stuff and implemented my own particle handling code.
I don’t understand though, why the GUI node doesn’t have the Z buffer? So if I put GUI panels there and set some panel to -1 Z and the other to +1 Z, they will just be rendered in the order that they are added to the node and Z won’t be taken into account?
What if all I need for a game is just to draw some textures (sprites) in 2D? Would you still suggest using camera, frustums and all this complicated stuff?
Thanks! :smile:

InShadow, yeah, these questions are for me too. However, I think that they are better asked in a separate (new) thread. Actually there are many questions I would like to clarify about 2D in JME (I just have to recall all of them). As I say, probably it is worth creating a tutorial on making 2D in JME…

I already said the objects are rendered back to front. I figured it might be obvious that “back to front” meant they were sorted by Z before rendering.

The GUI bucket is for 2D GUI stuff and for whatever strange reason therefore flattens Z during the render effectively ignoring the z buffer… but the objects are rendered in Z order.

Edit: I also said the gui node is fine to use for purely 2D stuff. Presumably sprites are 2D. :wink:

1 Like