```
This is the code that inserts morphTargets default behaviour to the vertexNode.
Now it seems to only be a matter of manipulation the node builder.
When you create a node using TSL, in the `Fn()` function goes first by default the node builder as parameter.
```javascript
vertexNode = Fn((builder) => {
...
})
```
I can access it this way.
`builder.addStack()` seems to be a prerequisite.
Then in theory I would have though `morphReference(mesh).toStack()` would have done the trick. Unfortunately it does nothing. I will probably need to dig again in the code to understand the `addStack()` and `.toStack()` behaviours.
Anyone has manipulated the node builder in a similar way already? And does it sound like a good idea?
It feels like the solutions lies here close by.
---
### Author:  [@Fennec](https://discourse.threejs.org/u/Fennec)
#### Post date: [July 8, 2025, 12:00am UTC](https://discourse.threejs.org/t/morph-attributes-in-tsl/84909/6 "2025-07-08T00:00:14Z")
This is purely theoretical, but what if you recreate the morph target inside your `Fn`? You can retrieve the original attribute and use the morph attribute as a temporary storage. Then, compute the final value using `mix(original, morph, weight)`.
---
### Author:  [@Rathalio](https://discourse.threejs.org/u/Rathalio)
#### Post date: [July 8, 2025, 12:29am UTC](https://discourse.threejs.org/t/morph-attributes-in-tsl/84909/7 "2025-07-08T00:29:31Z")
In theory, yes it would work to `mix(geometryPosition, morphAttributes.location, morphInfluence)`. Although maybe can’t see a good solution. But when I tried implementing that kind of logic, I had to create a custom attribute to retrieve the current vertexID and store `morphAttributes` in a uniform and iterate on it using the vertexID. And that’s when I discovered the size limit for uniforms among other issues. And overall I don’t think I have the level for a full implementation of morph targets.
That’s some more reason why I am trying to recover the default morph behaviour instead of reprogramming it.
Moments ago after more digging. I found out that the default code was returning `positionLocal`. I tried experimenting with it again. And it does almost work. In my code I was using `positionGeometry` which overrides everything. With `positionLocal` I’m getting the morph transforms back. The only issue I still didn’t manage to fix. Is that `positionLocal` is local mesh space and my transforms are not localspace. So it collapses to the origin now the further you get from the rest pose. I’m not really an expert on this. I understand the principles but I’m not so great putting them in practice sometimes. x)
I have a codesandbox with a minimal demo here if you are curious: [https://codesandbox.io/p/devbox/glsl-dqs-to-tsl-2j7lkn](https://codesandbox.io/p/devbox/glsl-dqs-to-tsl-2j7lkn)
Edit: PS: The morph target on the demo is what makes the pipe have a bulge on its end. If it’s straight, morph targets overridden.
---
### Author:  [@Fennec](https://discourse.threejs.org/u/Fennec)
#### Post date: [July 8, 2025, 1:48am UTC](https://discourse.threejs.org/t/morph-attributes-in-tsl/84909/8 "2025-07-08T01:48:48Z")
> [@Rathalio](#):
>
> The only issue I still didn’t manage to fix. Is that `positionLocal` is local mesh space and my transforms are not localspace.
Again this is pure theory, I’m still new to TSL myself, but maybe something like this would work:
```js
const worldPos = modelWorldMatrix.mul(vec4(positionLocal, 1.0)).xyz.toVar();
```
This _should_ transforms a position from local space to world space.
You can find a list of all available transformation matrices [here](https://github.com/mrdoob/three.js/wiki/Three.js-Shading-Language#model).
---
### Author:  [@Rathalio](https://discourse.threejs.org/u/Rathalio)
#### Post date: [July 8, 2025, 10:30am UTC](https://discourse.threejs.org/t/morph-attributes-in-tsl/84909/9 "2025-07-08T10:30:24Z")
I’ve tried more variations.
I’m convinced that now I understand what’s happening. When I’m using `positionLocal` instead of `positionGeometry`. I indeed retrieve the morph transforms. But I also retrieve the default skinning behaviour. So since the beginning I had no issue transferring data spaces. The problem is simply that the skinning is applied twice. Once with matrix blend and once with dual quaternions. So any transform kind looks like it’s twice as much as it should be.
Then that means I need to find a way that works to tell the material to disable skinning while keeping morphs. The classic `material.skinning = false` doesn’t seem to affect anything. But I remember seeing clauses enabling/disabling this in the source code. I think I can investigate and find a solution. If that works the code should be compact and elegant!
---
### Author:  [@Rathalio](https://discourse.threejs.org/u/Rathalio)
#### Post date: [July 8, 2025, 11:27am UTC](https://discourse.threejs.org/t/morph-attributes-in-tsl/84909/10 "2025-07-08T11:27:37Z")
The final solution was to was to use `mesh.isSkinnedMesh = false;` since `material.skinning = false` is ignored. This is a little bit hacky. But if the mesh is no longer treated as a skinned mesh by default it’s fine since anyways I override the `vertexNode` to skin it myself.
Now I just need to finish updating the normals with similar code and that’s a wrap.
[https://codesandbox.io/p/devbox/glsl-dqs-to-tsl-2j7lkn](https://codesandbox.io/p/devbox/glsl-dqs-to-tsl-2j7lkn)