When I scale the scene Node nothing gets scaled at all:
[java]
Node scene = (Node) GameState.getInstance().getAssetManager().loadModel(name);
scene.scale(3f);
[/java]
Only when I scale subnodes that have geometries as direct subnodes the scaling takes place.
Why does it break the basic scene graph concept: scaling a node should propagate to its children recursively.
Do you have physics controls attached in your model?
@wezrule said: Do you have physics controls attached in your model?
Yes. The level has a RigidBodyControl and some position marker nodes have GhostControl.
Is it correct that scaling a node should affect all subnodes recurively?
@mathias4u said: When I scale the scene Node nothing gets scaled at all: [java] Node scene = (Node) GameState.getInstance().getAssetManager().loadModel(name); scene.scale(3f); [/java]Only when I scale subnodes that have geometries as direct subnodes the scaling takes place.
Why does it break the basic scene graph concept: scaling a node should propagate to its children recursively.
If you scaled everything by 3, how can you tell if it is scaled or not? Remember, even their positions relative to each other will be scaled.
When you scale the individual sub-nodes, the positions stay the same and the scale changes individually.
I’ll refrain from also posting the scene graph docs because others have done that already. 
If you scaled everything by 3, how can you tell if it is scaled or not?
Because I also have DebugState which allows me to add a Box at the rootNode. This box keeps the same relative size in both cases, with and without scaling the node of the scene. I can only repeat. The scale has no effect.
BTW, the docs say nothing about how to scale physical objects, only how to move them.
Correction: The online docs say something while the SDK docs (F1) don’t.
You mix up several things here, mainly because you stick your head way further into the engine than your knowledge allows you to. I guess you talk about physics collision shapes and spatials at the same time here, not realizing they live in completely different environments and hence do not scale along with each other. Read the physics page and also read some more of the overall documentation. I see you are intelligent enough to work with the engine but without a proper overview you will end up in dead ends all the time due to quickly built preconceptions and misunderstandings like these.
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:physics
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
If you would forget about physics for a moment (because I do call scale() before attaching the scene to the scene graph and adding controls to the spatials and the physics space) how would you explain the position of nodes within a scene?
When I move a spatial within the SceneComposer the resulting code says that the spatial has ZERO local translation and some world translation. Problem with this is that when I want to move a spatial after loading the j3o file with
[java]
child.setLocalTranslation(Vector3f.ZERO);
[/java]
Then the spatial just stays at its world position instead of going to the origin. As per definition the origin is at 0,0,0 and if the LocalTranslation is also 0,0,0 then it has to be at the origin. The only thing that could be possible is that the SceneComposer changes the world translation of spatials instead of their relative position to the parent (which is at my case 0,0,0)
Simple question: How to move the spatial to the origin?
Now that the scaling of nodes that come from within a j3o file has no effect I have implemented a utility method that solves the problem.
[java]
private void scaleRecursively(Node node) {
boolean hasChildren = false;
for (Spatial child : node.getChildren()) {
hasChildren = true;
if (child instanceof Geometry) {
child.scale(1f * GlobalConstants.GLOBAL_SCALE);
child.setLocalTranslation(child.getLocalTranslation().mult(GlobalConstants.GLOBAL_SCALE));
} else if (child instanceof Node) {
scaleRecursively((Node) child);
}
}
if(!hasChildren){
node.setLocalTranslation(node.getLocalTranslation().mult(GlobalConstants.GLOBAL_SCALE));
}
}
[/java]
With this method everything works as aspected now. Meaning that all objects that were placed within the SceneComposer appear at the same relative location after scaling.
I have no understanding why the framework is doing a bad job at this very basic function.
@mathias4u said: If you would forget about physics for a moment (because I do call scale() before attaching the scene to the scene graph and adding controls to the spatials and the physics space) how would you explain the position of nodes within a scene?
We will only forget about physics if you stop using it and tell us if the behavior is the same or not.
Scaling works properly. I use it all the time. I don’t use physics.
And just to avoid obvious issues… which version of JME are you running?
Could it be that your camera is somehow attached to the node you are scaling? I am not sure if that is even possible, but in theory, I think that could explain your behaviour… I have never experienced this in jME, but in other scenegraphs.
Time to anwser some questions:
But fundamental problems like object properties with discrepancy between SceneComposer and what the code says directly after loading the scene from the file can’t be caused by physics. Example
NodeX in SceneComposer:
LocalTranslation = 1,1,1 and WorldTranslation=0,0,0
NodeX after loading the scene
LocalTranslation = 0,0,0 and WorldTranslation=1,1,1
Scaling within the SceneComposer seems to work as what the editor shows. But after loading the scene the scale has gone.
However, since I can scale the scene manually (with the utility method above) I can continue our work.
And no suprise for me: Physics works, even after scaling 
What is the shortcut Ctrl+S within the SceneComposer supposed to do?
I noticed that this shortcur starts scaling the current selected object depending on how far I move the mouse.
@mathias4u said: Time to anwser some questions: - I use the curent SDK - The camera is a ChaseCamera that is not attached to a specific node (?) - Yes, I use bullet physics (not native)But fundamental problems like object properties with discrepancy between SceneComposer and what the code says directly after loading the scene from the file can’t be caused by physics. Example
NodeX in SceneComposer:
LocalTranslation = 1,1,1 and WorldTranslation=0,0,0NodeX after loading the scene
LocalTranslation = 0,0,0 and WorldTranslation=1,1,1Scaling within the SceneComposer seems to work as what the editor shows. But after loading the scene the scale has gone.
However, since I can scale the scene manually (with the utility method above) I can continue our work.
And no suprise for me: Physics works, even after scaling
With your dismissive stance I am really not very interested in helping you much further but yes, it is caused by the PhysicsControl and its normal, it sets the physics object position each update call. And still most of the “strangeness” you experience is due to your preconceptions.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
I had a mistake in the sequence of building up the scene. I asked for the LocalTranslation after adding the PhysicalControl which built the problem in my head.
Sorry for my missleading statements.
I learned that Spatial.scale() has no effect if the spatial has a CompoundCollisionShape. The solution for me was to to build the CollisionShape after scaling the spatial. The online docu says that:
You can change the scale of collisionshapes (whether it be, Simple or Mesh). You cannot change the scale of a CompoundCollisionShape however. A sphere collision shape, will change its radius based on the X component of the vector passed in. You must scale a collision shape before attaching it to the physicsSpace, or you must readd it to the physicsSpace each time the scale changes.
This quote is not from the SDK docu but from the online docu. That’s why I was not aware of this behaviour. General question: Which version of the docu is more current? I have read somewhere that the SDK docu is always the correct for the current version of the SDK.
I tested the Spatial.scale() function again and I think that there is still a difference to my utility method.
It seems to me that Spatial.scale() only scales Nodes and Subnodes whereas my utilty method also scales the geometry spatials below a node. That would explain why CollisionShapeFactory.createMeshShape(levelNode) works with an unscaled mesh resulting in my problem that Spatial.scale() has no effect when using physics.
@mathias4u said: I tested the Spatial.scale() function again and I think that there is still a difference to my utility method.It seems to me that Spatial.scale() only scales Nodes and Subnodes whereas my utilty method also scales the geometry spatials below a node. That would explain why CollisionShapeFactory.createMeshShape(levelNode) works with an unscaled mesh resulting in my problem that Spatial.scale() has no effect when using physics.
Scale scales everything. It’s modifying the transformation matrix at that spatial that is then applied to all child world transforms.
Put together a simple single class test case. When that works then you can figure out what is different about your application that makes it fail. If the simple test case doesn’t work then you can post it here and we can show you what you did wrong.
I scale nodes all the time and all of the children are scaled as I expect them to be.
Note: I don’t use physics… which seems to be a factor in this case.