Character gets stuck within a mesh even though collisions enabled

[bigrig]

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:

Babylon.js Playground

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)

[alexchuber]

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:

Babylon.js Playground

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.

[bigrig]

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.

Babylon.js Playground

[alexchuber]

Ah, how did I miss that . Glad it worked out!

[bigrig]

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?

Babylon.js Playground

Here is that asset with just the floor: simplest case scenario:

Babylon.js Playground

[bghgary]

cc @Cedric/@RaananW

Note that they are on vacation right now, so it might be a few weeks before we get an answer.

[MarianG]

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

[mawa]

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.

Babylon.js Playground

[bigrig]

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?

[Takemura]

This topic might help:

Collisions on Flipped Normals

Firstly, the gltf/glb has right handed coordinate system and BabylonJS coordinate system is left handed. So you need to set scene.useRightHandedSystem = true before importing. Else you have to consider negative z-scaling, which can cause unpredictable collision problems. The main cause of the collision failure seems to be that the flipped mesh has inverted normals and also has a right handed coordinate system. Usually the triangles of gltf are counter-clockwise, while Babylons (left handed) are…

IIRC @bghgary wanted to modify glTF-importer, not sure if this is took into account aswell.

[mawa]

@Takemura

wanted to modify glTF-importer

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

[Takemura]

Found it:

Loading .babylon scene as a child of a specific scene graph node

There is some confusion in these posts, so I will try to clear some things up. SceneLoader has multiple ways for loading an asset (Load, Append, ImportMesh, and LoadAssetContainer), all of which have an async counterpart that returns a promise instead of using callbacks. Load will load into a new scene. Append will append to an existing scene. The only methods that will give you the meshes that come from the asset are ImportMesh and LoadAssetContainer. Here is a PG using ImportMeshAsync that wi…

[mawa]

Cool. But that’s a very long thread and a lot of discussions around it. I wonder how we could leverage this? @bghgary

[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.

[mawa]

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

[JooJ-Joestar]

I created this account just to say THANK YOU SO MUCH! You saved my 2024’s Global Game Jam game from being a gigantic mess.

I checked on Blender and some box colliders really had their scale set to a negative value somehow. By deleting such boxes and reinserting them with a decent scale value I got the desired result.

[mawa]

Glad to hear your game jam was a success. Now that you joined our forum, I hope we will be able to hear from you again Meanwhile, have a great day