Converted GLBs from FBX have morph Targets that affect lighting

Help & Support
1

Hello Everyone!

I recently came aross a peculiar Problem. When I view a 3 Model of a Character GLB with Morphs with the GLTF viewer from PlayCanvas then everything seems to be working correctly. But when I import an FBX File (Exported from Blender with Shape-Keys, same file but now as FBX) of the Same character with the “convert to GLB” option enabled, morph animations then weirdly affect the lighting of the character. And it does so on every morph Target.

I have recorded a short clip here, where I first load the GLB file with the GLTF viewer (everything works accordingly). Then I open a window which was opened by clicking “Open in Viewer” in the Editor on a Converted (imported as FBX) GLB file in my PlayCanvas Project and get weird results. This does affect one of my applications, where a character then is weirdly lit when playing a morph animation.

Any idea on what I could do here?

I also had an older project with the old animation system and playcanvas-gltf.js and playcanvas-anim.js where I loaded a glb animation and added this as a new animation clip. There everything works properly.

Does this have anything to do with recent updates?

2

We have some issue importing morph target normals from fbx files. @slimbuck tried to solve this but without a success at the moment. One of the option to avoid the issue is to not include normals for blend targets in the fbx, if this is something you have control over.
The other could be to instruct the engine to ignore the normals when morphing … but we don’t have an API for this, and is something we’d need to add.

2 Likes
3

Okay thank you for the tips!

So this is a known issue. I’ll keep an eye on any updates then :slight_smile:

Thank you!

4

@mvaligursky looks like i’m running into the same issue, is there some place we can track the progress @slimbuck is making on this bug?

5

We only have internal issue logged on this so far … feel free to add a public one here to track progress.

Do you need morph target normals or not? If not, there are some possible workarounds.

6

I need normals, as its a characters face with morph targets that are procedurally animated.

7

In this case, the only workaround is to export your fbx to glb elsewhere (Blender), which might preserve the blend normals better, load this at runtime and render it this way. At least till we get some time to fix our side, which we tried and didn’t succeed few months ago.

8

Did you guys get any further with this issue?

I’m also trying to do some facial animation on an imported FBX that uses morph targets and it messes up the lighting due to the normals shifting.

I haven’t tried exporting as GLB yet, because I’d rather avoid having to do that if possible. So just wanted to check in and see if there’s any progress on this.

9

There has been no update on this unfortunately.

10

We recently encountered this problem on a project. Had to spend a bunch of time digging around for the source problem. We found that even a simple box experienced this issue.

Screenshots from opening the glb in the built-in Viewer, with Render Mode set to WorldNormals:

Morph 0.0
Morph 0.01417×999 13.7 KB

Morph 1.0
Morph 1.01417×999 66 KB

Has there been any progress on this issue? Even the proposed workaround for disabling normal morphing would be fine. Has this been implemented?

11

@sijo_animech - what specifically is the issue in your case? If you have glb with position and normal morphing, and use it in the viewer, I would not expect any issue. The normals should be morphed correctly and affect the lighting. If you do not want normal morphing, exclude normal morph targets from the glb.

12

If we export an object with morph targets as FBX, import it into PlayCanvas, and use the morph target we get these normal artifacts. Both GLB or JSON show the same problem.

When looking at the GLB or JSON data, we see that it contains normal morph information (deltaNormals). However, the data is garbled and of no use. For the box example shown above, there shouldn’t be any changes to the normals. If we manually zero out the deltaNormals the normal artifacts disappear. This is not a viable workflow though.

Our studio uses 3ds Max, which can’t export GLBs directly without a bunch of other issues (such as not exporting morph targets…). Also, the FBX exporter doesn’t have an option for excluding normal morph targets. In fact, if we look at the source FBX (when exported as ASCII rather than Binary) it doesn’t seem to contain any normal morph data, so it seems like the PlayCanvas converter invents this on its own.

1 Like
13

interesting that the fbx does not seem to have morph normals, @slimbuck - this would be worth looking into how this is handled.

14

Sorry for my slow response on this issue @sijo_animech. The best will likely be to add an option to ignore morph target normals at import time. We’ll get this added asap.

1 Like
15

Okay, on a second look the FBX does have entries for morph normals. My bad. It’s just that they’re all zero. Snippet from the ASCII FBX:

	Geometry: 2061669767840, "Geometry::Box002", "Shape" {
		Version: 100
		Indexes: *4 {
			a: 0,1,4,5
		} 
		Vertices: *12 {
			a: 0,-50,0,0,-50,0,0,-50,0,0,-50,0
		} 
		Normals: *12 {
			a: 0,0,0,0,0,0,0,0,0,0,0,0
		} 
	}

Compare that to the converted JSON:

"deltaPositions":[0,-50,0,0,-50,0,0,0,0,0,0,0,0,-50,0,0,-50,0,0,-50,0,0,-50,0,0,-50,0,0,-50,0,0,0,0,0,-50,0,0,-50,0,0,0,0,0,-50,0,0,-50,0],
"deltaNormals":[0,0,0,0,-0.707107,0.292893,0,0.707107,0.292893,0.707107,0,-0.292893,-0.707107,0,-0.292893,0,-0,0,0,0,0,0,0,0,0,0.292893,-0.707107,0,0,0,-0.292893,0,0.707107,0,-0,0,0,0,0,0,-0.292893,-0.707107,0.292893,0,0.707107,0,0,0]
2 Likes
16

any chance you can send me the model for testing @sijo_animech ?

17

Yeah I tried to before, but the forum has strict file type limitations. I created a playcanvas project instead where you can download the source fbx.

18

wonderful TAM!