When I execute the code, the cylinders that make up the posts of the fence are floating horizontaly in the air.
This is not good. They are supposed to stand verticaly. The code responsible for their creation and orientation looks as follows:
//This cylinder will act as the four main posts at each corner
Cylinder postGeometry = new Cylinder("post", 10, 10, 1, 10);
Quaternion q = new Quaternion();
//rotate the cylinder to be vertical
q.fromAngleAxis(FastMath.PI/2, new Vector3f(1,0,0));
postGeometry.setLocalRotation(q);
postGeometry.setModelBound(new BoundingBox());
postGeometry.updateModelBound();
This is supposed to create a cylinder and rotates it from its default orientation (horizontal) into a vertical position.
But the rotation simply does not take place. Does anybody know whats the problem here? Thank you in advance.
I created a simple testcase where I essentially use the above code snippet to create and rotate a cylinder and attach it to the root node. This works as it is supposed to. So it must be the wider context of the Lesson4 code that prevents the expected result from taking place.
I then modified the code of Lesson4 a bit. In the original code, the Cylinder postGeometry ist used to create objects post1 to post4 of the type SharedMesh and localy translate them to create the four fence posts in their respective positions.
I simply added a local rotation to each post:
SharedMesh post1 = new SharedMesh("post1", postGeometry);
post1.setLocalTranslation(new Vector3f(0,0.5f,0));
post1.setLocalRotation(q);
SharedMesh post2 = new SharedMesh("post2", postGeometry);
post2.setLocalTranslation(new Vector3f(32,0.5f,0));
post2.setLocalRotation(q);
SharedMesh post3 = new SharedMesh("post3", postGeometry);
post3.setLocalTranslation(new Vector3f(0,0.5f,32));
post3.setLocalRotation(q);
SharedMesh post4 = new SharedMesh("post4", postGeometry);
post4.setLocalTranslation(new Vector3f(32,0.5f,32));
post4.setLocalRotation(q);
But I'm not really satisfied with this solution. I still would like to understand why the tutorial code does not work as expected.
I already tried that. It has no effect. I also tried -90 instead of FastMath.PI/2. And I dont think that PI/2 corresponds to a rotation by 180 degrees (which of course would be invisible in case of a cylinder). Because 2PI corresponds to a rotation by 360 degrees. Therefore PI/2 should correspond to a rotation by 90 degrees, because PI/2 is exactly one quarter of 2PI. Therfore PI/2 should correspond 360/4 which is 90. PI/4 would correspond to 45 degrees. But thank you for your suggestion.
Hi Mikkel,
I already tried that. It has no effect. I also tried -90 instead of FastMath.PI/2. And I dont think that PI/2 corresponds to a rotation by 180 degrees (which of course would be invisible in case of a cylinder). Because 2*PI corresponds to a rotation by 360 degrees. Therefore PI/2 should correspond to a rotation by 90 degrees, because PI/2 is exactly one quarter of 2*PI. Therfore PI/2 should correspond 360/4 which is 90. PI/4 would correspond to 45 degrees. But thank you for your suggestion.
Ah yeah my bad.
We never learned about radians in my school, and I guess I was a bit too quick. :p
Kind of strange that it didn't work then :(
- Mikkel
EDIT: Could it be because you update the model bounds after the rotation switch?
EDIT: Could it be because you update the model bounds after the rotation switch?
Good suggestion, I had this idea too. Unfortunatly no succes. I tried two variants to check this:
1. executing the rotation after after model bounds update. No success.
2. just commenting out model bounds update. No success.
@ all: how are your experiences with lesson 4 of flagrushtut? Please feel free to report even if you have no clue whats going on. Am I the only one who experiences this behaviour? Or have others too? I'm very eager to learn more about this!
Isn't this caused by SharedMesh being changed a while back so the meshes don't share rotation with the 'parent' mesh?
The flagrush code used to work so that the shared cylinders stood upright, but some jme update caused them to lie flat instead with no change in the flagrush code.
excellent suggestion! Right now, I dont know if you are right, but at least it is fully consistent with the results of my experiments to explore this issue (see my second posting in this thread). I'll try to check what you said. And thank you.
I seem to recall someone volunteering to update and continue the flagrush tutorials a while back. Is he still at it?
Btw, did you guys ever look into the MaterialState.java fix for the blueing of the flag that snareoj found?
-Changing the line
public static final MaterialFace defaultMaterialFace = MaterialFace.Front;
to
public static final MaterialFace defaultMaterialFace = MaterialFace.FrontAndBack;
seems to fix the issue of a blue backside on the flag.
