Exciting news! And… um… new Documentation… dun dun duuuun

@kobRoah said: What i'm thinking about is not nested like this it's more : - rootNode > MyNode > Collidable(Geometry) |-> GUINode

The GUInode isn’t the child of “Collidable(Geometry)” but child off “rootNode > MyNode”

On the provided exemple before, when i tryed what you wrote it works, no point about it, but when i try it how i need it to work, it doesn’t.
Well it make me end with using a control XD Pretty simple in fact :
[java]package mygame.tonecontrol;

import com.jme3.renderer.RenderManager;
import com.jme3.renderer.ViewPort;
import com.jme3.scene.Spatial;
import com.jme3.scene.control.AbstractControl;

/**
*

  • @author roah
    */
    public class ToneControl extends AbstractControl {
    private InteractiveNode toneNode;

    public ToneControl(InteractiveNode toneNode) {
    this.toneNode = toneNode;
    }

    @Override
    public void setSpatial(Spatial spatial) {
    spatial.getParent().attachChild(toneNode);
    toneNode.attachChild(spatial);
    super.setSpatial(spatial);
    }

    @Override
    protected void controlUpdate(float tpf) { }

    @Override
    protected void controlRender(RenderManager rm, ViewPort vp) { }
    }[/java]
    Let me know what you thing about the control, there is some issue on this since but hey :D, here is the idea…
    Ps: i forgot to mention the control only work if attach to something with a parent, well on some way there is no need of the control otherwise, even if i feel like it will be more easy to use, having a Control more than a Node.

Yeah… the geometry must reside somewhere under the extended node to work properly.

As for the control, one of the things I’ve opted to avoid is controls as a default solution in most cases. The library is careful to add/remove element controls (if they are required) only when they are actually being used. The reason this is done is because having a great number of controls has a fairly significant impact on Android’s frame rate.

For instance, buttons are only a control if you enable buttonStillDown type behavior and then the control adds itself when pressed and removes itself when released. to ensure that you have only 4 or so controls associated with the GUI library at any given time (Screen, AnimManager, EffectManager & the one control being used by the user…)

I’m pretty sure, that aside from Button’s still down behavior, there is only one other Element-base gui control in the library that does this sort of thing.

As for the use of extended nodes, another solution is to:

Load the model:
Transfer all geometries from the Model’s root node to your extended node and name it appropriately.
Continue as if you hadn’t done this.

Because the extended node is just a Node, all of the behavior, methods, etc are exactly as they were if you hadn’t decided to use this.

hi @t0neg0d,

@t0neg0d said: As for the control, one of the things I've opted to avoid is controls as a default solution in most cases. The library is careful to add/remove element controls (if they are required) only when they are actually being used. The reason this is done is because having a great number of controls has a fairly significant impact on Android's frame rate.

For instance, buttons are only a control if you enable buttonStillDown type behavior and then the control adds itself when pressed and removes itself when released. to ensure that you have only 4 or so controls associated with the GUI library at any given time (Screen, AnimManager, EffectManager & the one control being used by the user…)

I’m pretty sure, that aside from Button’s still down behavior, there is only one other Element-base gui control in the library that does this sort of thing.

Interesting. I got the problem, now let say i got “one” InteractiveNode and all my object are child of this node, when the node is trigguer, how can i/we get the geometry who have been hit ? right now how it work is : all child of the InteractiveNode trigguer the event, but the event, (MouseButtonEvent evt) didn’t have any field who give an idea of the object directly hit.

@kobRoah said: hi @t0neg0d,

Interesting. I got the problem, now let say i got “one” InteractiveNode and all my object are child of this node, when the node is trigguer, how can i/we get the geometry who have been hit ? right now how it work is : all child of the InteractiveNode trigguer the event, but the event, (MouseButtonEvent evt) didn’t have any field who give an idea of the object directly hit.

use:

[java]
screen.getLastCollision();
[/java]

Sorry for the delay in response. I didn’t see this.

Thanks :smiley:

Edit :
hi @t0neg0d,
Is it normal that the screen.getLastCollision event always return me a null pointer ?

1 Like