BufferAttributes in BufferGeometry.morphAttributes once set, can never be updated

[Ithamar]

Describe the bug

There seems to be no way of updating morph target values (the vertices in position attributes, in my case).

To Reproduce

Steps to reproduce the behavior:

Simply grab an attribute from geometry.morphAttributes.position[], update the values in the array, and set the attributes needsUpdate to true, and wait for nothing to happen :(

Expected behavior

Either Mesh.updateMorphTargets() should trigger a refresh or needsUpdate on the morphattributes should be honoured (or yet-another-method should be available to do so).

[mrdoob]

Any chance you could provide a jsfiddle?

[Mugen87]

I believe this is a current restriction in WebGLMorphtargets. The morph target texture is only updated if a) it does not yet exist or b) the count of morph targets has been changed. It does not check if one of the data of one of the existing morph targets has been changed. Granted, this is an edge case and not something that happens with imported animated models.

needsUpdate on the morphattributes should be honoured

Implementing this check produces a bit of overhead since you have to check each morph target per frame for an update. Since a geometry can hold many morph attributes, I would prefer a different approach.

Either Mesh.updateMorphTargets() should trigger a refresh

That sounds like a better place. The only downside is that calling this method reset morphTargetInfluences which is in some sense an unexpected side effect. Besides, you need a new private flag which can be evaluated in WebGLMorphtargets.

Alternatively, we could introduce a new public flag BufferGeometry.morphTargetsNeedsUpdate.

Or, we just state this use case is not supported and the user has to create a new instance of BufferGeometry.

[Ithamar]

I love the idea of BufferGeometry.morphTargetsNeedsUpdate actually, follows the general 3js naming/mechanism, and with a few lines of documentation, makes it all work as expected.

Thing is, I ran into all of this when using BufferGeometry.scale, which does not handle the morphAttributes, obviously. So I set out to implement it myself, for my specific use case.

Anyhow, if you guys would accept a PR for this I'd be happy to have a stab at the morphTargetsNeedsUpdate flag (including docs).

[Mugen87]

I ran into all of this when using BufferGeometry.scale

Using Object3D.scale is not an option?

TBH, I'm hesitating to change the code base because updating existing morph targets is normally not something common.

[Mugen87]

I guess we should add to the documentation that the direct or indirect usage of BufferGeometry.applyMatrix4() does not affect morph attributes.

[Ithamar]

I ran into all of this when using BufferGeometry.scale

Using Object3D.scale is not an option?

No, I'm generating/editing geometry, and in this instance, it includes morphAttributes.

Regarding the documentation, if this feature is unwanted, I'd simply add a note to the morphAttributes documentation that once these have been setup, they cannot be changed anymore, and recreating the Geometry object is the only way. I think I've seen similar things in other parts of the documentation (like the count in InstancedMesh and such).

[Mugen87]

I'd simply add a note to the morphAttributes documentation that once these have been setup, they cannot be changed anymore, and recreating the Geometry object is the only way.

That sounds indeed better than adding a note in context of BufferGeometry.applyMatrix4().

[Mugen87]

I've filed a PR for clarifying the documentation as suggested, see #24254.

As a first step, I think this is sufficient. If more users request updating existing morph targets, the introduction of BufferGeometry.morphTargetsNeedsUpdate (or an alternative approach) can be reconsidered.

[aknoerig]

I have a use case in which this is behaviour is indeed needed (I believe): I am continuously (and on-the-fly) generating new offsets positions to all vertices of a mesh, so that the shape is continuously morphing from one shape into another.

The way I had implemented this was with just one morphTarget. The positions would morph from the original position to the target. Once there, I would update the original position attribute and morph to those. Then update the morphTarget and morph to those, etc. –– basically morphing back and forth between the two, and updating the one once the other is reached.

This was working fine until I upgraded from r128 to the latest release r145. (The only code change I had to do was to remove material.morphTargets.) Now this is no longer working.

Would you have any suggestions on how to make this work again? Basically, the need is to allow infinite morphing.

[aknoerig]

@Mugen87 please see my comment above - how would you suggest to handle this kind of continuously changing morphTarget?

Would this justify a morphTargetsNeedsUpdate function?
I could recreate the geometry at every step, or whenever the number of available morphTargets is exhausted, but that seems inefficient and cumbersome.

[Mugen87]

It looks like your use case can only be properly supported by having a new morphTargetsNeedsUpdate property. However, the new morph target implementation would perform badly if the number of active morph targets would constantly change (since on each change a new data texture has to be created).

[CITIZENDOT]

If more users request updating existing morph targets, the introduction of BufferGeometry.morphTargetsNeedsUpdate (or an alternative approach) can be reconsidered

I would like if such option is available on geometry. By default, we can set it to false. Going through the code, I see we've to add the condition here

three.js/src/renderers/webgl/WebGLMorphtargets.js

Lines 45 to 47 in 19b0eeb

	let entry = morphTextures.get( geometry );
	if ( entry === undefined || entry.count !== morphTargetsCount ) {

to

if ( entry === undefined || entry.count !== morphTargetsCount || geometry.morphTargetsNeedsUpdate )

If that is all needed, I can make a PR for this.