Importing an FBX file with multiple ( and parented ) models should have the same setup in PlayCanvas

Currently when you import an FBX file of a scene or model to be interacted with ( within which the artist would have set up the various separate models, possibly parenting and animating some of them to reflect the required result ), the same hierarchy in the modeling package should be reflected in PlayCanvas.

Take an example of a car - the artist has modeled the car, and has separately modeled and animated the 4 doors, as well as the boot/trunk and hood/bonnet.

In other packages that I’ve used, these FBX models are imported and are presented in the same way, making it relatively easy to interact with the scene - and more importantly, for the artist to update the FBX and for it to be merged in easily.

With PlayCanvas, the scene comes through as a single entity, with no way to access the individual models.

This takes relatively simple single export and import process, and turns it into a laborious task of multiple exports, one for each part. This of course costs time, and also adds in more opportunity for error.

Having a tick box to allow for the FBX hierarchy to be preserved would be of great benefit to speeding up and simplifying workflows.

You may not be able to see the individual mesh instances in the editor but chances are that it is in the graph node hierarchy.

You can check by printing out the entire graph in the console and reference them by findByName on the entity/graph node.

Not great but doable.

Hi yaustar,

Thanks for the info.

I was able to access the sub-nodes via code, but I wasn’t able to manipulate them individually ( translate, enable ).

Here’s an example scene, open up the console to see the messages showing that the enabled and translate functions seem to run on the data, but not visually.

Forked it and had a quick look.

The Cube.001 mesh instance is part of the cube that is animating, 2BoxesOneAnimating. Since there is an animation playing, it overriddes the local position of the mesh instance that the script has set it too.

Here is the scene hierarchy:


If I disable the animation component on 2BoxesOneAnimating, I can see the mesh instance Cube.001 has been moved.

Not sure about disabling the node, I see need to look into that.

@Mal_Duffin I think I got to the bottom of this.

TL; DR Here’s the project where I hide/move one of the ‘sub meshes’:

With the models, all the separate meshes in the FBX are a pc.MeshInstance that have a reference to a pc.GraphNode for name, transform etc. However, there is no link from the node back to meshInstance.

The enabled property in pc.GraphNode only stops the update event fired to it. It’s not linked to whether it gets rendered or not (maybe it should?). The model component on the entity removes the model from the scene on enable and disable of the entity so it appears to have slightly different behaviour.

Again, not great. It be nice to see it in the editor to hide/make visible etc again.

Edit: Thinking about it, it is possible to add the reference in the node to the meshInstance as part of the initialisation step.

Cheers for having a look at this yaustar.

Do you know what the teams thinking was behind combining the entire FBX into a single entity in the editor?

From a usability point of view for the 3D projects I’ve done in the past, not having access to the sub entities in the editor means a lot more work / cost.

Whatever the initial decision, having a tick box somewhere to disable this for some projects would be great.

I don’t think it is something that was or could be ‘disabled’. It was never a feature of the editor AFAIK.

My guess is that they wanted the editor to show the entity hierarchy otherwise they will be lots of various nodes (extra noise in the editor) for every mesh instance that could potentially be edited (by accident) and difficult to debug why there is a difference between what the artist sees and what is in the editor/published build.

On top of that, having access to the graph node doesn’t help in this case as it doesn’t have a reference to the mesh instance to hide it from view.

The question could be asked is if you are going to move/edit these different models in the FBX, why is it one exported as one file?

That said, I can understand the workflow shortening but can’t think of a middle ground that retains the original vision of the editor at the moment to suggest to the team.

On Unity my artist was used to export tens of meshes in one fbx. All overlapping over each other at coordinates 0, 0, 0. As at end we were working with names and all the meshes packed in one single file were used in the same scene and sharing most of the textures and materials.
Then he was enabling them one by one to setup the materials and create prefabs from each if them.
Later, when some changes were needed on one or more assets he was exporting them all together again without spending time thinking what or not to export.

Just bringing this up again, as I’m now trying to manipulate children of the FBX in a current project.

It’s a major PITA not being able to deal with a child of the FBX in the same way as a child of the root entity ( eg .enabled ), but thanks to @yaustar I have a work-around for that ( luckily I remembered this thread from last year, as I had been trying the .enabled code for a while wondering why it wasn’t working ).

I’m currently trying to clone one of the elements within the FBX, does anyone know if this is possible?

I would have thought so as it’s just a graph node pointing to a mesh instance. The potential issue might be dealing with reference counting to the asset.

Hi @yaustar

I put an example project here, to see if there was a way to get the clone to work.


Had a quick look at the engine code and a stab at it.

Not sure how much of a hack this is but it seems to be ‘ok’. I don’t think I’m doing too much outside the box here.


1 Like

Hi @yaustar,

Cheers for sorting that out, I’ve added that code back into the main example.

@yaustar, if you check that same example ( ), on line 194 there is an issue when you try to clone the clone ( graph is null ).

Do you know what else needs set on the original clone, so that it can be cloned itself?

I’m guessing that it is because we haven’t used a model asset :thinking: