@Vinc3r No, the parent relation stays in place (which is what I want).
@JCPalmer and @Evgeni_Popov, thanks for the feedback. As to “why” I wanted to do this, my asset container holds the 6 objects in it, through which I want to loop through each mesh and set some initialization to them (textures, state property, etc.). The parent element of the group needs some slightly different settings, so my plan was to have the parent be index 0 and apply its settings, then loop through the rest.
Name becomes complicated in that through the instantiating, a number of
Clone of... names and id’s get set, so it is challenging to locate by that.
It appears my asset container that is loaded has a “meshes” property that directly accesses the meshes, but when I set the “state” property on those, the settings did not persist in a way that was locatable by
pickResult.pickedMesh.state on a pointerDown event. In looking at a console.log of my mesh, the “state” property I ended up setting doing it that way is buried deeper in submeshes it seems with the instantiation. So instead of accessing the “meshes” property of the asset, it seemed I might have success getting the “state” set where I wanted it on each object by going through the
rootNodes of my loaded asset (which I thought and/or wanted to be the parent) and then also looping through children.
Any further advice on understanding the structure of what I’m receiving in the asset load, and how to best access the meshes on instantiation to set properties, would be appreciated. In the demo for the
onPointerDown function, he uses various
.getChildMeshes(), so I’m trying to get a handle on my own stuff to figure out (or set) my structure so I know where to set/get the information I need.