Hi all.
My characters are getting stuck in my cloned meshes (cloned from a sub-mesh within a GLB). Any idea what to do to prevent? Been debugging for a day, to no avail. Finally got a PG that replicates the behavior:
Turn around when you get in the PG - here you can see he’s stuck in the floor of the room on the left (the one with collisions enabled)
Hey there!
You could fix this by cloning the root only, then iterating through the root’s descendants and setting checkCollisions from there. Here’s a PG:
The cloned instances in your playground are being inserted to the scene as root nodes (no parent).
While I’m not certain, I think that loss of transformation data from the original instance’s ancestors is what’s causing the issue.
Thanks. I should have elaborated more on my objective, which is to clone individual sub-meshes from a parent GLB. Like - to just clone the couch.
In your PG, it looks like you’re putting collisions on the original mesh instead of the clone. But your theory about the parent is spot on! By cloning into the parent, all problems go away. Oh I’m so excited about this. It has been driving me crazy for many moons.
Ah, how did I miss that 
. Glad it worked out!
Im still having this problem - but now in a different way:
Where character is getting stuck in meshes again - even though they have collisions enabled. Any idea what prevents the collider from working?
Here is that asset with just the floor: simplest case scenario:
Note that they are on vacation right now, so it might be a few weeks before we get an answer.
Hi, I think your object has some faces where the normals are inverted. Most of the time this is the reason why the objects get stuck while colliding
Or - In this case scenario, I think I detected the root of your instances being scaled at -1 on the z-axis. Which in turns, does the same as inverting the normals when it comes to collisions. I thought this had been fixed but may be you should check on it == try change your parent root to scale 1 on z. Apparently this fixes the collision issue. Of course, it will mess-up the entire scene but essentially, I guess it means you should get rid of this node if you want to instantiate from hierarchy with colliders (as in the solution above). In which case, create a new root that does not use negative scaling.
Hm. In my app I let users bring in their own GLBs (this is one of those user generated GLBs for example).
I’m looking for a foolproof way to allow for import and to add colliders. So, that sounds like a step here in the import sequence that checks for negative scaling on the z axis - and a check for inverted normals (is it possible to check and fix normal inversions programatically)?
Maybe sounds like an option we could consider adding to the Babylon importer method or instantiateModelsToScene?
This topic might help:
IIRC @bghgary wanted to modify glTF-importer, not sure if this is took into account aswell.
Yes, I also kind of recall someone (not sure who) saying we would likely fix this issue for collisions handling. For however its done (and whoever does it), it would sure be appreciated 
Found it:
Cool. But that’s a very long thread and a lot of discussions around it. I wonder how we could leverage this? @bghgary
Sorry for the slow response. I was on vacation.
I’m not sure what we are saying will be fixed. The links to my posts are not related to collisions.
My apologies. I admit I didn’t really read your linked post 
I was just trusting @Takemura that this would be related.
FYI: The topic here was about handling collisions on import (of glb or gltf) when the mesh or instance is at a negative scaling. Which, in turns, causes the collision not to happen since it only happens from the front side (UV) of a mesh. I guess we had hopes here that, when setting the mesh as a collider, it could be somehow detected and fixed…automagically 
…in the spirit of BJS 
