Problem getting mesh from J3o (but not xml.ogre)

1

I have been playing whit animated texture for a while now and for the moment the plan was just take the node, break it into geometry by going into every child this node have and then creat a new sptatial from that geom, set is material to be the animated material and then apply the whole thing inside the first node.

It work great for anything build using the xml.ogre file, but the j3o one have wierd result. The animated texture model is usely way too big, and very far from the first model

private void applyAnimatedTexture(ModelVisuel targetedNode, Spatial child, Material mat)
{
     if(child instanceof Geometry)
     {
        Geometry solidTexture = new Geometry() ;
        solidTexture.setMaterial(mat);
        solidTexture.setMesh(((Geometry)child).getMesh());
        targetedNode.attachChild(solidTexture) ;
     }
     else if (child instanceof Node)
     {
         for(Spatial subChild : ((Node)child).getChildren())
         {applyAnimatedTexture(targetedNode,subChild,mat) ;}
     }
 }

Why does it behave like that? What is wrong whit this little code :confused:

2

The j3o probably has a hierarchy of nodes with their own transforms and stuff. By taking the individual geometries outside of their transform hierarchy then you lose all of that. Local becomes world, and so on.

Either duplicate the hierarchy or make sure to put the copy of the geometry at the same world translation, scale, and rotation.

1 Like
3

Indeed, thanks. I can use the child value to resize and replace. I still donā€™t untherthand tho : why do the J3o have all those wierds resizing on import?

4

It depends entirely on what the source scene looked like and how you imported it. You didnā€™t really explain the difference in your original post.

5

Well, usually the model was WAY bigger (the local scale was something like 0.0625) and also far, far away from where it was supposed to be. I updated the method now, so it should not be a problem anymore, but I also just took the model and put every variable at 1,1,1 for scale and 0,0,0 for position and rotation and it look the same, just not facing in the same direction but it was not the right one to begin with.

Fact is I already have a resize done on the model when I put it in the game, because some of the assets are ogre.xml so I donā€™t really have the choice. It just felt weird to have a double resize/reposition every time.

6

I mean, I donā€™t know where your j3o came from that you are talking about is ā€˜messed upā€™. j3o had to have been imported from something else. That something else had transformations in the hierarchy.

7

So you mean its taking direcly every resize and translation in the blender file?

PS : Or actully pretty sure those model was import from blender using ogre

8

Yes, JME is not manufacturing this information. It was in the original ā€˜sceneā€™.

9

But then why donā€™t it simply assume everything is just at 1,1,1 ? Because tecnicly for im this is the normal size of the asset. I donā€™t see where this coordination on the resize could be usefull :confused:

10

Ok, letā€™s say you have a robot. That robot is made up of a body. That body has children that are arms and legs. The arms and legs have children that are hands and feet.

Letā€™s also say that the hands and feet are 100 units big normally but because the robot is human sized, they have been scaled down to fit. If JME automatically made those 1,1,1 then your robot would look really strange.

JME is not making these values up. They were in your scene. They are CRITICAL to the proper rendering of your sceneā€¦ or they wouldnā€™t be there.

The scene graph hierarchies translation, rotation, and scale is fundamental. Itā€™s possible to apply all of these transforms before exporting.

ā€¦but blah blahā€¦ hand waving guessā€¦ blah blahā€¦ I donā€™t know where the original scene came from, what it looked like, what format it was, or anything necessary for me to remotely comment further.

What I can say for 1000000000000000000000000000000000000000% fact is that JME didnā€™t pull these values out of thin air just to make your life tougher. They existed in the original data. JME cannot make assumptions about throwing them away.

1 Like
11

No i mean I underthand that, i know now its not creating anything, what i mean is why donā€™t JME actully pull new value yet assume the resize as he is in the file its importing from. meaning the model see imself as a 1,1,1 but in the back office its actully the 0,065,0,065,0,065 so that when we take the mesh on the model we donā€™t see something that never existed but the actual size its in the J3o file.

12

You arenā€™t. Either you arenā€™t explaining yourself clearly or you havenā€™t understood what Iā€™m saying.

13

Maybie a little bit of both xD Anyway thanks, its work now :stuck_out_tongue: Iā€™ll come back if am able to speak my mind in a more clear way.

14

Looks to my like the model is out of center. Normally models have a zero-point quite in the middle of it and this is also the origin of scaling. So if the center-point is off-center, the scaling will in some cases look like ā€œthe model gets further awayā€.

1 Like