Postprocessing Ignores Morph Targets & Normals

[ghost]

When a morph target mesh is rendered with a non-morph target material, the mesh seems to render in bind pose. The EffectComposer framework for postprocessing uses the scene.overrideMaterial interface to generate depth and normal buffers, so these buffers have all meshes in bind pose. You can see the issue by applying a normal buffer postprocess to the MD2 character example.

I've badly hacked up three.js to take a scene.morphOverrideMaterial parameter to use as an alternate override for meshes which originally had a material with the morph target flags. I also updated the post processing effects to provide morph target variants of their override materials, and it allows them to render correctly on animated characters.

I could share my hack, but I think a better solution would be to use the morph target and morph normal settings from the true material of a mesh, even in the presence of an override material setting. (Or... does webgl have multiple render targets?)

[mrdoob]

Can you create a jsfiddle showing the issue?

[Mugen87]

The EffectComposer framework for postprocessing uses the scene.overrideMaterial interface to generate depth and normal buffers, so these buffers have all meshes in bind pose.

I think that's not true. MeshDepthMaterial and MeshNormalMaterial include the respective shader chunks for morph target and skeletal animation. You just have to set the material properties skinning or morphTargets to true.

Besides, the material viewer of the documentation easily shows that morph target animation works (activate morphTargets in the section THREE.MeshDepthMaterial).

https://threejs.org/docs/index.html#api/materials/MeshDepthMaterial

When a morph target mesh is rendered with a non-morph target material, the mesh seems to render in bind pose.

That's correct. It's your task to ensure that morph targets are supported by the material which is intended for scene.overrideMaterial. EffectComposer can't do this for you.

[ghost]

Well loading the post processing stack into jsFiddle has proven to be a complete pain, and I barely remember the details after so long and after we've just switched to a custom renderer to solve everything at once... However, I am 100% sure there were multiple booleans including "morphTargets" and "skinned" which I brute force tried every permutation of by hand to no success, and also am sure that scene.overrideMaterial was being used to generate some input buffers for the SAO pass because manipulating that override material directly was the only way to achieve animated normal buffers. Maybe it's just the SAO pass with the problem, and not the EffectComposer itself.

[pawelstan]

Hey!

Wanted to bump this issue.
SAO was working well for me with my animated models in Three ver. 0.89.0!

I just added:

	this.depthMaterial.skinning = true;
	this.depthMaterial.morphTargets = true;

	this.normalMaterial.skinning = true;
	this.normalMaterial.morphTargets = true;

in THREE.SAOPass constuctor.

But after upgrading to version 0.92.0 it stopped working. I've added skinning and morphTargets in all other materials used in SAOPass.js with no luck.

I can see that depth and normal buffers have all meshes in bind pose.

I have set the skinning or morphTargets to true, otherwise they wont animate at all.

@Mugen87 Any ideas what changed from version 0.90.0 that could affect this?

[Mugen87]

No, sry. There were some bug fixes related to SAOPass this year but I don't think they should affect your code. https://github.com/mrdoob/three.js/commits/dev/examples/js/postprocessing/SAOPass.js

[pawelstan]

Found the problem. It was spot light helper, it is breaking the sao on skinnned meshes...