Is there a way to make a spatial ignore selectively part of the “inherited” transformations from an ancestor after the attachment?
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.
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’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.
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:
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).
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.