Console flooded with failed to validate json using api

(Shaderbytes) #1

Any material changes done via the api ( v1.4.2 ) the console gets flooded with :

Failed to validate json…
“channels.x” should match exactly one schema in oneof …


Do you have a live example?

(Shaderbytes) #3

sure , here are my code pen examples for my documentation of the utility :

here is an example with zero textures uploading , just working with scene loaded stuff. I can assign a texture without issues , but if I remove a texture I get the console warnings. I posted in another thread there is actually a usability issue here , because the object graph does not have a color property if a channel had a texture assigned to it in the editor.

Im getting around this problem in my utility by checking for this problem and then creating and assigning a color object before the texture is removed :

if (channelObjectRef.color === null || channelObjectRef.color === undefined) {
     classScope.setColor(materialName, channelName, null, "#ffffff");

without this hack the texture is not removed … the api just bombs out silently … well it throws these same console warnings i mentioned but nothing happens in the scene

Ok so back to this … so I have this workaround and this does work , as in the texture is removed … but I still get the console warnings.

Now for a even worse example … this time a scene is loaded and the objects have no texture assigned. I am then uploading a texture and assigning it to 3 materials , 1 channel in the first , two channels in the second, 3 channels in the 3rd.

Here is where you will see it flood the console.

All examples are using 1.4.2 and my latest api version which was recently refactored for 1.4.2 so all is up to date.

So that is two examples to investigate :

• removing a texture from a material that had one assigned in the editor

• assigning a texture to an object at runtime that loaded without a texture initially.




Thanks. Weird that it works as expected still…

@paul_sketch ?

(Rémy Bouquet) #5
  1. Many material channels need either a color or a texture. Not both, and not none of them. That’s why you get this warning when you remove a texture.
    Note that when the material has neither of them you end up in an undefined state where you can’t guaranty what’s is going to be displayed. Hence the warning. I don’t feel that it’s a hack to make sur the material has all the information needed to be rendered properly.
    So basically in your applyMaterialUIDPending method, when you set a texture remove the color from the material (like delete json.color), and the other way around, when you set a color delete the texture. Then always make sure there is at least one of them.

  2. All validation warning are just this… warnings. So if it works as intended, you can just ignore them. If you send both color and texture, the texture will prevail I think, but there is no guaranty that this will always be the case.

(Shaderbytes) #6

i see thanks :wink:

I can make edits for both ways but i must say It does seem like more trouble than good to enforce only one data point.

Just to point out , in the first example where i say i add the color as a hack, I should not get any warnings then as i have a color and im removing a texture , which should satisfy your requirement for only one or the other. It a bit of a catch 22 now… it seems to validate the duality before evaluating the api action. So there is no way around a warning now … since i cant set a texture while there is a color , and i cant remove a color while there is a texture because it seems it is either gonna have both properties or none at some point within that pipeline if validation happens before the action is considered … i hope you get what im saying.

I did mention it in another thread , why cant color just always be there… i mean its an array of three floats per material , the size increase of the data for that is trivial. As you mentioned you already have a system where a texture will prevail over a color.

This way you can add or remove textures without any care of setting the color as the color will always be there :wink:

For setting a color , it should always set it , but if a texture is found present it should then just output a warning to the console that the texture has to be removed to see the color.

So then the only other console warning is if both are not present , as this obviously leaves the material in a state that cant be rendered.

anyway thanks for the input i appreciate it


( sorry for the delayed edit , my internet went down in the middle of editing my post )

(Rémy Bouquet) #7

Well we have many internal reasons to not allow color AND texture, but we could think of making the process more seamless for the user.
Though I’m usually not fond of automagically fixing “wrong” inputs to an API for several reasons:

  1. You cannot exhaustively predict how wrong the data will be, so your check might be bogus and just add overhead for nothing.
  2. You don’t educate the user, and cope with his lack of knowledge of your API.
  3. I agree making things seamless and easy for users in the editor is very important, however in the viewer API perspective, where users are most often developers, I guess they can understand that the underlying system lives under some constraints, and expects to be fed valid data.

(Shaderbytes) #8

Thanks for the info , You guys obviously have good enough reasons to do as you have :wink: I will make the needed changes in my utility.

chat soon