Decals are not supported for glb files

I’ll take a deeper look into this example, thanks!

It looks like if these two lines from CreateDecal were changed to be like below then the decal’s initial position and rotation could be computed accurately even if the mesh was deformed by skeleton or morphing. It might not make sense to do thou because the decal wont stay stuck to the mesh if it’s animated anyway, but if the animation is paused or stopped then it seems to work well (from my testing with the model in the OP)…

const positions = sourceMesh.getPositionData(true, true);
const normals = sourceMesh.getNormalsData(true, true);

Oh, checked here and that seems to do the trick! I think we could control this through an optional flag, something like applySkeletonsAndMorphs, as these functions are slower than getVerticesData. Want to do a PR? :smiley:

I’m not sure it’s the solution, as @Blake pointed out it won’t work when the mesh is animated (the decal won’t follow the animation).

It must be something specific to the model as @MarianG showed in https://playground.babylonjs.com/#ISZ7Y2#66 that decals can work even with animated models loaded from a glb file…

EG if I pause the animation in that shark PG and rotate to check diff parts thou, I can see that the decals are wrong for many parts of the mesh because the skeleton isn’t applied…

Also the original PG had some other issues, I got it working by removing the predicates from the picking and passing the pickedMesh to CreateDecal. Here’s the PG I used for testing with the skeleton applied (it stops the animation when a mesh is picked to test that the decal is created properly).

IDK what the solution is for keeping the decal in sync with the animated mesh thou. :frowning: The proposed changes would only help with paused/stopped skeleton animations and non-animated morphs I guess…

1 Like

Here’s a simpler PG to reproduce the warning “Setting vertex data kind ‘position’ with an empty array” with just a simple box mesh. If you comment out line 37 that disposes the old decal the error goes away. IDK what the issue with disposing them is. :thinking:

EDIT: moved this part to a new bug report. :slight_smile:

1 Like

Hi,
@Blake u r right if animation is stopped its working well…
i think decals does not support Rigged avatars. i tried with t-pose avatar its working
Need to find some workaround to apply for Rigged avatars.

Hmm there’s an older thread discussing a work-around using a dynamic texture. They also ruled out using attachToBone() which I hoped might work for this. Maybe @ozRocker will have some more insights about it? :pray: :slight_smile:

I never had a proper Babylon.js solution for this. I’m still using a Python call to a compiled Blender module to bake the decal on the same UV map

1 Like

@Blake You’re right, I think the new (decal) mesh would need to have the matrix indices/weights filled correctly as well as using the same skeleton than the source mesh for decals to work correctly for rigged characters… I will try to have a deeper look about this issue.

4 Likes

Oooh awesome, it would be amazing to support! :beers: :slight_smile:

@Evgeni_Popov want me to create a Github issue to track progress? :slight_smile:

Yes, thanks!

Support skinned/skeleton meshes on decals · Issue #13084 · BabylonJS/Babylon.js (github.com) :slight_smile:

2 Likes

Thanks @Evgeni_Popov for the support

2 Likes

Small teaser:

(it’s still a work in progress on the coding side)

7 Likes

Its more than a teaser :slight_smile:

You’re the fastest webgl wizard on the west :slight_smile:

Nearly there!

If not using the new “Culling back faces” flag, you can get a “leak” of the decal on the back, depending on the depth of the projector (meaning the z component of the decalSize parameter):

5 Likes

you rock