Json children from an imported REVIT FBX not getting right position

Hi everyone!!
I imported a fbx created in Revit to Playcanvas. The json was created automaticly and so far so good. The problem comes when I try to reach the different components to make them move. At first, I can getPosition of the different parts and they are correctly positioned when I see them in console.log. However, when I try to gather them in a variable (for example to make them move) their position changes and they are situated in 0,0,0 or very near to cero.

The result is that when I try to move components instead of starting in its right position, they go automaticly to 0,0,0 and then they move. I want them not to change their positions.

Question: Checking already in console.log that they register the right position. How is it possible that one read correctly the position and when one wants to take it for movements it changes putting them in origin? (dissapearing the original coordinates of the components).

If someone has a clue about what is happening, I will be thankful!


Can you share a link to your project?

Hi vaios!!
thank you for your quick answer!!
I don’t know how to do it exactly… with this link is enough or should I do sth else?


Can you point me in the right direction? Where in your code is there a problem - what should happen?

oh, yeah, sorry, I deactivated the lines with problems and I forgot to activate them and I will try to be more specific.
The problem starts in the “animation.js” script. In lines from 204 to 219. There it is written:

var pureba = jsonObj.model.meshInstances[84].node.getPosition();
//var purebay = jsonObj.model.meshInstances[84].node.getPosition.y;
//var purebaz = jsonObj.model.meshInstances[84].node.getPosition.z;

   this.parts = [

The meshInstance [84] is a window and I want it to move forward in z. This window is well positioned in the 3d model apparently, so, it is showing the console.log(pureba) variable. Then, this mesh, with others, is gathered in this.parts for ulterior movements. These moves are managed in lines up to 305. There it is written:

        for(i = 0; i < this.parts.length; i++) {
            // position
            pos = this.parts[i].getPosition(); //OBTIENE LA POSICION
            //pos = this.posInitials[i];
            //this.parts[i].setPosition((pos.x), (pos.y), (pos.z));// SITUA LA NUEVA POSICION
            this.parts[i].setPosition((pos.x + (posTotalModelX - pos.x)*  this.easing), (pos.y + (posTotalModelY - pos.y)* this.easing), (pos.z + (posTotalModelZ - pos.z)* this.easing));

There for each part the position is got, however, not the right position but (0,0,0). The original position of the meshInstance[84] (and any other because I proved many) dissapears and is placed in the origin. This happens already when I´m gathering the meshInstances in “this.parts” code.

One can test that the window is in the right position in the 3d model, just deactivating the lines related to meshInstance[84].

Well, dont know if this is helping or my explanation is too entangled… :S

I’m not sure I follow the code - when I place a breakpoint at line 305 I see this.parts[i[.getPosition() get called and return the position of that mesh instance. It’s not 0,0,0 - each one has a different value.

I suggest placing breakpoints all over your code and try to follow what’s happening from the initialization up to the point where you see the problem. This is 99% a problem with your code somewhere so try to eliminate PlayCanvas being the problem here. There is probably a problem in your logic there somewhere.

Perhaps try to replicate the problem in a more isolated case and work from there. If you have a more isolated case with a simple script that shows the problem we can help more.

Thank you for the reply!
actually when I meant (0,0,0) I didnt meant exactly this number but sth very near to, for example, 2.83746747474 e-45 (scientific numberstyle), that means 0.000000000000000000000000002837… blablabla… so to speak zero. Did you check it was not sth like this? with e-45 or whatever at the end?

If it wasnt like this probably you r right, so I’m not an expert on the subject and I cannot refute your expertise. If it was like this scientific number with “e-45” at the end, it might be still the code I’m using but it could be also that the original position of the component is lost, not keeping their original position (I think its original position was sth like 6.0749999, -0.699999,-0.1550000 that appears in the console.log when the lines 216, 368 and 369 are deactivated). If these lines are activated this position turn into near 0,0,0.

However, I take your point and I will put some break point on the run, so I can take a closer look.

Thank you very much

PS: the picture down shows the original place of the meshInstance[84], the second pic shows the “new position” of the meshInstance[84] when I’m gathering in the variable this.parts and of course you can see also that the window is placed incorrectly in the point near (0,0,0) because it has lost its original position.

So in your code you have these variables

posTotalModelX = 0;
posTotalModelY = 0.3;
posTotalModelZ = 0;

Then in the update method you are doing

for(i = 0; i < this.parts.length; i++) {
    pos = this.parts[i].getPosition();
    this.parts[i].setPosition((pos.x + (posTotalModelX - pos.x)*  this.easing), (pos.y + (posTotalModelY - pos.y)* this.easing), (pos.z + (posTotalModelZ - pos.z)* this.easing));

So this will move each part to that 0, 0.3, 0 position. I guess that’s not what you want to do? I mean the other parts except that window seem to be positioned so that 0, 0.3, 0 is their correct position but that window is not at the right place when its position is at 0, 0.3, 0. You can see in the console after the animation has finished that all your parts are at that place 0, 0.3, 0. So you should probably either fix the model in the 3d studio you’re using or adjust the position of the window in code so that it’s moved to a different more correct place.

Uhmmm… I cannot agree with you

the variables posTotalModel are numeric variables only modifying the vertical postition after getting the real position of the components.

In the code text, first the position is got and then the got position (i. e. pos.x that should be the original) is set in this formula:

pos.x + (posTotalModelX - pos.x)*this.easing … that means … “originalPosition”+(0- “original_position”)*0.2

so, posTotalModelX, in this case cero, shouldn’t have influence at all in the original position of the element. In the case of Y, is the same

pos.y + (posTotalModelY - pos.y)*this.easing = “originalPosition”+(0.3- “original_position”)*0.2

That is what I understand, but I should be mistaken because it is a fact that the thing is not working so. Where is my mistake?

PS: absolutedly discarded the idea that the 3D model is wrong. If I choose other window it happens the same. and as you see they are all placed correctly.

When you call setPosition you are changing the position of the Entity. This does not modify the original position it modifies whatever the current position of the Entity is. So when you call getPosition() you are getting the modified position back after you changed it with setPosition in the previous update loop.

If you want to change the original position you need to store it somewhere at initialization like so:

this.initialPosition = part.getPosition().clone()

However I don’t think that will do what you want since it seems to me (and correct me if I’m wrong) that what you want to do is ease the parts to their target position. So what you are doing in your code is correct but you are setting the wrong position for that window.

That sounds convincing to me. Thanks!
yes, I’m trying to move the different parts to a target position.

However, after your explanation, it comes a question.

Well,every “switch” case in the code is begining with getPosition of the parts. Why for the window is not getting the original position at the beginning? in other words: in which previous loop am I changing the position if every case of switch is getting the original position as initial reference?

Of course, after the first setPosition the component won’t have the original position, but at the begining should have, Shouldn’t they?

Yes and they do. If you breakpoint at lines 208 and 317 in the beginning, you will see that meshInstance 84 has this position:

6.074999809265137, -0.699999988079071 , -0.1550000011920929

I put breakpoints in those lines. In 208 it is ok, in 317 I have to take a closer look because it seems is not giving me these values but always since the begining (0, 0.3, 0) – coinciding with the values of the posTotalModel as you told me before… uhmmmm… I’ll check again.

ok. I put a breakpoint in line 317 and I follow what it is doing since the begining and how the value x,y,z is changing.

You are absolutedly right!! however, I´m not satisfied with this because it is not explaining the behabiour of the mesh[84].

The meshInstance[84] has his original coordinates at the begining but this mesh is behaving different than the others. Look, I put a console.log in this loop to register what it is happening on case 2 of my code.

You will see that the other meshes are still and keeping their positions but this [84] is changing (and note that this [84] is not treated differently to the other meshes in my code!!), so, I think there are two possibilities or maybe linked in one: the mesh [84] has some characteristic different from other meshes that makes the calculation in the background different compared to the other meshes.
What do you think about this? Am I crazy?

PS: when I refer to the mesh[84] in fact I´m speaking about all those meshes of the windows because with all of them is happening exactly the same.

My guess is that the pivot point of that mesh instance is different than the others in your model. So I’d suggest you go into the modelling studio you use and check if that’s the case there with that mesh instance.

Yeah, I will try to check this, but I think in the program I´m using there are little possibilities of changing this. :frowning:
because windows are already children of walls.
Anyway I will try to find a solution.

Thank for your patience and good day!!

1 Like