MorphTargetManager has uniform binding problem

Bugs
1

Hello, I am working on custom model loader and using the MorphTargetManager, and I have encountered a problem while rendering models where the morph target exists.

The errors are as follows(in firefox)
WebGL warning: drawElementsInstanced: Tex unit 0 referenced by samplers of different types: SAMPLER_2D_ARRAY (via morphTargets) and SAMPLER_2D (via boneSampler).

and as a result, the morph targets are not functioning correctly.

Playground that reproduce error:

Code to load the morph target used to reproduce the error:

It is possible that I have been using the Morph Target Manager incorrectly, which may be causing this issue.

please help.

2

Your PG does not work, because your are using some private functions that have been renamed in a PR yesterday:

image
image1036×117 7.88 KB

1 Like
3

When will the next version of babylon.js be published on npm?

4

I think we release npm packages every friday. cc @RaananW to confirm.

5

Next package will be released tomorrow (6.10.0). Every Thursday at 00:00 PST

1 Like
6

Thank you for your answer! I’ll tell you again when I fix the PG.

7

I fixed PG now. If it does not work, try disable cache.
Thank you in advance.

edited+
I just found the problem. It seems that when a MorphTarget does not have position data, it causes issues. Is this intentional? If so, then I need to include position data unnecessarily when generating UV morphs.

8

Yes, “positions” are currently mandatory. An error should appear in the console log if you do not provide a morph target for the positions:

const positions = target.getPositions();
const normals = target.getNormals();
const uvs = target.getUVs();
const tangents = target.getTangents();

if (!positions) {
    if (index === 0) {
        Logger.Error("Invalid morph target. Target must have positions.");
    }
    return;
}

I’m not sure why positions are mandatory, though…

cc @sebavan, maybe we could lift that restriction.

1 Like
9

Makes sense to be able to lift the restriction

10

First of all, I think it’s not a bug, but it’s just a problem caused by my lack of understanding of how morphtarget works. I’m sorry to bother you.

It seems structurally difficult to resolve.

In the current implementation, there seems to be room for writing incorrect code in this scenario:

morphA - [positions, normals, -]
morphB - [positions, normals, uvs]

Both morphA and morphB include positions and normals, but morphA does not have uvs information.

Generally, in such cases, the user’s intention for morphA would be to indicate a morph target without uvs. However, the behavior of the actual implementation would make it appear as if an array filled with zeros was used.

I think specifying this as a consideration or requirement can help reduce confusion

11

Actually, a morph type (normal, uv, tangent) will be enabled only if all targets define one. In your example, morphA does not define uvs, so uv morphing is disabled.

If you still want to use uv morphing, you will indeed have to define a uv array for morphA and set an influence of 0.

12

If you look at this PG, it seems like doesn’t work that way.

In the code, morph “A” is a morph that moves the position, and there is no UV morph data.

And morph “B” simply retains the original position and UV data.

However, if you look at the result, you can see that it is strangely distorted.

This issue indicates that in order to use UV morphs, all morph targets must have UV morph data.

13

It should work, there’s a bug when creating the morph texture in this case.

This PR will fix the problem:

2 Likes
14

Thanks a lot!