As mentioned last time, today’s post is a bit of a “non-post”: it talks about adding a SkinnedMesh to be animated alongside an underlying skeleton, which we already know doesn’t currently work inside the Forge viewer. But it’s instructive to see the process in case either the situation changes or someone wants the code for a pure three.js application.
Basically it’s possible to add a SkinnedMesh into a render overlay or into the main scene, it just doesn’t get animated along with the skeleton itself.
Here’s a screenshot:
Here’s a video that gives a better sense of what I mean. Look closely to see the skeleton moving but the mesh staying still.
The issue is buried in the guts of the Forge viewer: basically the viewer has its own render loop where it chooses the objects it updates and displays. This is probably for performance (or just historical) reasons, but that’s just a guess on my part. Either way, the code that updates SkinnedMeshes is not included in the custom render function used by the Forge viewer. If you want to take a look at how it should work, check this Fiddle. It includes the Forge viewer code and the most recent build of three.js to show how both work (the newer three.js is overriding the Forge viewer’s implementation, if you remove the three.js reference you’ll see how Forge’s three.js tries to animate them). There seems to be a bit of strangeness in three.js r71, but that’s not completely surprising, given its age. It does raise the issue that enabling the update of SkinnedMesh objects in the viewer may not be the only thing that’s needed to get them work properly, though.
Here’s the overall code to add SkinnedMeshes that don’t get animated by the Forge viewer:
In the next post we’re going to forget all about SkinnedMeshes and look at what we can do to thicken the display of the graphics displayed by the SkeletonHelper object.