JS error when switching material variants if not all model parts have variant definitions (intentionally) #3086
Comments
|
I think I might have found a more definitive case. In the above demo, I have added one more model: 'Primitives XOX'. This also causes the JS error. I noticed in the original Faucet model that 2 of the 3 nodes had variants defined in the GLB, but the third had no variants, as it doesn't change material between variants. I created a new model, 'Primitives XOX', with 3 basic primitives. 2 of the primitives (cone and cube) have material variants defined, the sphere has no material variants defined. This new model causes the same JS error. |
milesgreen
changed the title
|
Updated title to be more specific to what I now think the issue is caused by |
|
Modified initial error description to be more specific to what I now think the issue is caused by. |
|
@timmmeh I can repro this on master; would you mind taking a look when you're around? |
|
@milesgreen thanks for tracking this down |
|
@milesgreen can you provide the Primitives XOX model, its blocked from download in the glitch sample |
Resolve an async bug that occurs when two nodes reference the same material. The first node starts loading a material and marks it as loaded, then while waiting for Three to complete the actual material setup the second node begins loading the same material and which is now marked as loaded thus it tries to fetch the cached material which is not actually available because the first node was still waiting on Three.
ghost
mentioned this issue
|
I setup a local test to reference the model and was able to patch this bug. |
|
Sorry @timmmeh. Been AFK and only just seen your request for the GLB. But looks like you’ve already resolved it? Let me know if you still need the sample GLB. |
|
No problem and it looks resolved so I shouldn't need that anymore, I can always reference it directly, just can't drop it into the editor but no biggie, thanks again for pointing this issue out. |
|
Just in case: |
Resolve an async bug that occurs when two nodes reference the same material. The first node starts loading a material and marks it as loaded, then while waiting for Three to complete the actual material setup the second node begins loading the same material and which is now marked as loaded thus it tries to fetch the cached material which is not actually available because the first node was still waiting on Three. Co-authored-by: timmmeh <tirichards@google.com>
|
Can confirm that pulling from master after this commit has indeed fixed the issue I was seeing on the above demo page. |
Description
I noticed that some models with particular material variants cause an uncaught JS error when changing
variantName.It appears that it is caused when there are multiple nodes in the GLB and some nodes have variant definitions and some parts don't.
This is an intentional scenario where there might be a model with multiple variants for some parts, but other parts don't change between variants. EG. For a model of a car, the bodywork might change paint colour, but the wheels wouldn't.
See demo:
https://modelviewer-materialvariant-test.glitch.me/
View the demo. Select the 'Primitives XOX' model from the first dropdown (default). Then select the 'Green' material from the second dropdown. A JS error is thrown. Cone and Cube should turn green, Sphere should remain black. But only Cube turns green. Now select another material. Now select 'Green' again, and this time no error occurs, both Cone and Cube are updated, as expected. So it appears to only affect the first time that variant is applied and subsequent applications work fine.
See the JS Console for the following error:
All the other models in the demo link work, as they all define variants for every node.
Live Demo
https://modelviewer-materialvariant-test.glitch.me/
Version
Browser Affected
OS
AR
The text was updated successfully, but these errors were encountered: