clearColor not working

[435352980]

Hi, i'm using ModelViewer width version 5.0.0-beta.12 It seems like clearColor not working.

 const viewer = new ModelViewer(canvas);
 viewer.gl.clearColor(0.244, 0.246, 0.249, 0.5);

old（v4.8.6） new (5.0.0-beta.12）

also with model combine old（v4.8.6） new (5.0.0-beta.12）

[flowtsohg]

I think that's the page behind the canvas that you are seeing, because you are clearing with 0.5 alpha. If this is indeed what you want, you can pass your own WebGL options when you construct the viewer, e.g. new ModelViewer(canvas, {alpha: true}), or have a black HTML element behind the canvas. By default the viewer sets alpha to false, because it's generally not needed, and supposedly it allows browsers to go for a more optimized code path.

/edit With that being said, note that some of the blending operations don't use alpha, and will break if you clear with a non-1 alpha (as can be seen by the second model). I don't remember the exact rules of what happens, but I also encountered these issues in the recorder client.

[435352980]

Yes, i put the canvas element in a drawer that width white bgcolor. I checked my code, find that i passed null to init the ModelViewer new ModelViewer(canvas, null) because i confused environment for my project, sorry. Some item effects with black color, so i change it. I modify my code and checked all models, find one model eyes behavior is different from old version.

const viewer = new ModelViewer(canvas);
viewer.gl.clearColor(0.244, 0.246, 0.249, 1);

old new model file abi.zip

[flowtsohg]

Are you sure that's the same model for both versions? I glanced at the contents of the model, and I can't really see anything (global sequences, layer alpha animations, geoset alpha animations, texture animations, bone visibility animations) that would actually cause the eyes to blink, but I might be missing something. That being said, there is that Z fighting next to the eyes, not sure what that's all about.

About the background - generally speaking you probably don't want a black one, because like you saw, it makes things hard to see if they are black :D I usually set mine to black for testing stuff just because I like the color.

[435352980]

I create a demo about this on https://twrpg.fun/RecordFile/modeltest It can click right top span to change old or new viewer version.

[flowtsohg]

There are three issues: 1) The Z fighting which is visible in both versions. 2) The eyes not opening at all. 3) The eyes opening incorrectly.

I have no idea why the Z fighting happens, are the two face meshes actually derived from the same geometry? The weirder thing is that this Z fighting doesn't happen in WE, wheres for example the Z fighting on the neck ribbon is visible in both.

The eyes not opening is because your geoset alpha animation denotes something close to 0 as invisible, but not quite 0, and my code checks for an exact 0. This goes back to the days of not quite knowing what the threshold is. In other words, how much alpha do the geoset and layer need to actually be rendered.

Now for the third issue - even if I "fix" my code, e.g. check for any alpha > 0.1 or whatever threshold, the animation is still not the same. In fact you can see it in the gif you posted above. The eyes close a lot earlier than they should. This is actually what the data is - the keyframes aren't correct, so that both of the face meshes are drawn in some of the frames (which is when you see the Z fighting). Replacing the order at which the faces are drawn- geoset 1 and then geoset 0, instead of geoset 0 and then geoset 1 - fixes this by drawing over the needlessly visible close-eyes mesh, however nothing in the data tells me to do this, as far as I can see. That is, this is the loading order of the geosets/materials/geoset animations, and both of the layers are opaque and have priority plane 0. And again, in WE it works fine 🤔

[flowtsohg]

I changed the condition to alpha > 0.01 in beta.14, so the behavior is similar to v4.

Still not sure about the rest.

[flowtsohg]

After all of this time, this issue is fixed. Since before I started working on this model viewer, in previous works of other people, no one ever had a correct implementation of MDX animations. They were all very close, but all wrong in different ways when missing the beginning/closing keyframe of an animation. @Retera figured it out, and we can finally get correct animations.