Ignore some of ancestor's transformations

Is there a way to make a spatial ignore selectively part of the “inherited” transformations from an ancestor after the attachment?

Example:
P is a node which stores a scaling and a rotation.
Q is a child of P, which stores no transformations.
S is a child of Q, stores no transformations and gets affected by Q’s transformations (which happen to be none) and P’s. I want S to ignore P’s scaling but respond to P’s rotation. Is it possible without altering the scenegraph?

Nope. It defeats the entire purpose of the scene graph. I mean, even “position without scaling” isn’t entirely clear. Do you want the object itself just not to be affected by scale or the position too?

ie: if it’s locally at 1, 1, 1 and scale is 10 then do you want position to be 10, 10, 10 or?

You might want to explain what you are actually trying to do because the question itself indicates that you don’t really want to manage these objects as part of a scene graph in the first place.

Hi @pspeed, thanks for the fast reply.

Ok, I’m trying to assign a geometry a “fly by” spatial which translates and gets scaled in accord to what happens to the first one, but keeps its initial rotation in any case. My current solution is assigning both to a node and applying every transformation to this node, which makes things super easy for what concerns scaling and translating. These node is then attached to a “master node” which stores a translation and a rotation. I want the flyByObject (and only it) not to be affected by the master node’s rotation.


EDIT: Sorry for this, but I’ve just realized I haven’t explained the problem the right way (and probably wasn’t approaching it correctly). I need the flyByObject to be affected by the rotation around the masterNode, but keeping its “local” rotation (I mean the rotation around its own center).

I’ve got a similar issue. In my case, a spatial is considered as a GUI element and must always have the same size on the screen, but it is attached to another Node to follow.

The only solution I found is to rescale it manually. Maybe there is a way to achieve such rich relations between nodes using a Custom Control.

Please give feedback !

I’d still be interested if you can explain in more real world terms what it is you are trying to achieve rather than scene graph constructs. It has too many assumptions already built into it so it’s hard to say what alternatives might be.

My problem’s is similar to @methusalah’s, but ok, I’ll be as explicit as I can.
I have to divide my geometries into two sets, one in the upper half of the screen, one on the lower half. This two sets are represented by two nodes, let’s say upper and lower, which are directly attached to the rootNode. Their creation process goes like this:

  • The node is created and then translated on the lower half of the screen, so everything will be attached to it will get the translation automatically (this happens for lower).
  • If a parameter is set to true, it is also rotated by 180° and its translation negated, so it goes to the upper half of the screen and everything will be attached to it gets the rotation automatically too (this happen for upper).

An entity is a node to which a geometry is attached. A flyByObject could also be attached to entity, and is supposed to follow the geometry and always stay on top of it; it also has to always mantain its rotation around its center since a flyByObject has a top and a bottom end and the entire object would be meaningless if upside down.
All the istance of entity are either attached to lower or upper. If an entity is attached to upper, it gets rotated by 180° around the upper node, so the flyByObject will be upside down.

I want the flyByObjects to be rotated around the upper node while keeping at the same time their own rotation (around their own center) constant.

Ok… but WHY are you trying to do this?

Like “I want two different views of the same scene like split screen.”
Or: “I want a map view on the top…”
…or some ‘logical’ explanation.

Because, for example, both of those have WAY easier ways to accomplish it.

…and all of the other cases I can think of are likely a problem of treating spatials like game objects. Which even if you don’t want to redesign around that we can still help with approaches if we know what the end result is actually supposed to do. Not in "this geometry and that geometry’ terms but in “My horses and cowboys” or “My planets and space ships” or whatever terms.

See this conversation as to why we like to know that stuff:

I just followed @methusalah’s hint and ended up with something like this.

public class Main extends SimpleApplication
{
    @Override
    public void simpleInitApp()
    {
        final Node intermediate = new Node("intermediate");

        intermediate.rotate(.0f, .0f, FastMath.HALF_PI);

        final Node entity = new Node("entity");
        final Geometry geometry = new Geometry("geometry", new Box(.5f, 1.5f, 5f));
        geometry.setMaterial(new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md"));

        entity.attachChild(geometry);
        intermediate.attachChild(entity);
        rootNode.attachChild(intermediate);

        geometry.addControl(new AbstractControl()
        {
            @Override
            protected void controlUpdate(final float tpf)
            {
                final float zRotation = spatial.getWorldRotation().toAngleAxis(Vector3f.UNIT_Z);
                spatial.rotate(.0f, .0f, -zRotation);
            }

            @Override
            protected void controlRender(final RenderManager rm, final ViewPort vp)
            {
                // EMPTY
            }
        });
    }

    public static void main(String[] args)
    {
        new Main().start();
    }
}

This should keep the rotation provided by (and around) intermediate, and adjust the rotation around geometry’s center at every refresh.

At certain points in the game, a Pawn of my table-top-like game gets a temporary property. I want the player to know about that property being held by the pawn, hence I make an object spawn on the pawn (pun intended).

Some more explanation that may help


both tools are in the same scene graph, placed at the spatial location.

The blue one have to keep its screen size and scale accordingly to the cam distance

The pink one size is “scene space dependant”, but its screen proportion is kept : the torus keep the same thickness accordingly to the cam distance.

Both of them are manually placed at the same rotation/translation than the spatial, but their scale is independant.They are not child of the spatial.

I take that opportunity to ask about my own issue if the OP don’t mind, because i’m interested in the subject. It might also be one your yours.

To draw these tools I have two choices :

  • place them in the transluscent bucket for them to be on the top. It’s perfect but FXAA filter don’t pass on them.
  • place them in the transparent bucket, with an AdditionalRenderState().setDepthTest(false); The FXAA works but I have issues with z-buffer and my tools are covered with shadows.

I think their is a better way to do this. Having a parallele scenegraph? a second viewport with other filters?

What do you think?

Thanks and good luck :smile:

I think if you want filters to affect them then they need to be in the same viewport. I don’t remember whether fpp was ever modified to be able to span viewports.

If you want them drawn last then just make sure they are drawn last. Either make sure that are in the transparent bucket and make them closer or set a custom comparator that always sorts them in front or whatever.

…if you want them not to cast shadows and not to receive shadows then you need to turn depth write and depth test off. Which will probably solve several of your issues already.

Okay thanks for your this, I was close to the solution.

I finaly want to prevent shadow reception on my geometries with

geom.setShadowMode(ShadowMode.Off);

but something goes wrong :

Do you now what’s happening?

Ok, now I am really off topic, sorry for that ^^

If you are using the shadow post filter then there is no way for objects to not get shadows unless they don’t write depth… since shadows are done in post.