How to edit more complex 3D options through API?


(Klaasnienhuis) #41

I'm running into this issue while patching my models. It appears it searches for a matcap texture which it can't find. Removing the texture part from the matcap material doesn't work, nor does setting the matcap texture uid to an empty string or null. I'm not using matcap, but the api still tries to find this texture.
Can you tell me when this is fixed?


(Stephomi) #42

@frederic_cambon ETA? ^


(Tribble42) #43

We'll try to have it fixed by next week


(Klaasnienhuis) #44

@stephomi @tribble42, that would be great, thanks!
btw, are you migrating all V2 model-patch features to the V3 API? Or is patching materials going to die out? That would be a disaster for my projects.


(Solsnare) #45

^ Exactly the same question.

Long term solution is a must!


(Instasafari) #46

It looks wonderful ! :tomato:


(Klaasnienhuis) #47

@stephomi, @tribble42,
any word on this update? And if you're at liberty to say I'd really like to know if the V2 model-patch features I'm using right now will be deprecated eventually. Or will you also implement these material patches to the V3 API?


(Tribble42) #48

Hey @klaasnienhuis sorry for the late answer

We are not going to deprecate V2.
However, yes, V3 is a more future proof version.
We're considering adding more options patches to the V3 but to be honest, nothing has yet been discussed regarding more custom patches (like v2).
The issue being that we change the format of the options regularly and it's easy to break any user's integration of this API.


(Klaasnienhuis) #49

Thanks,
I understand about the regular changes. In my case that's not really a big deal. I only use this API when uploading configurable models, or models in bulk. After that I use the viewer API in the live website. So the patch stuff is more on the production side and the viewer API is on the customer side.

But perhaps there are use cases where the patch API is used in a live environment where regular changes are less practical. Though I can't think of them.

The way I deal with the patches is that I get the entire set of options from the model, modify what I want (like setting material colors or post processing options) and then patching it back. this way, any new features are automatically supported, because I don't touch them. But if there's an internal issue, like now, this clearly doesn't work. But in general, I haven't had to change my code after new options are added to the API.


(Solsnare) #50

@klaasnienhuis Beat me to the punch, but i fully agree with what he's implying.

As long as the paradigm of me
1. pulling the options
2. editing the options
3. sending it back through a patch request

stays functional, the specifics of how you want to format the data doesn't matter as much,

I am OK with your updates to the formatting as long as it'll still be possible to edit the same options, irregardless of where and how the data is formatted.

At the least it'd be nice to do a little forum post informing us if there are any changes however, but even without that, i wouldn't mind.

Thanks a lot for helping us here,
please keep us informed on the status of this, i'm still in limbo till it's fixed


(99idea) #51

Thanks.
ซ่อมไอโฟน


(Antheny) #52

I also want to know


(Klaasnienhuis) #53

@stephomi @tribble42,
I've noticed the matcap texture issue has been resolved with the API. Thanks!
When I now try to patch a recently uploaded model I get the collowing error
(400) Bad Request.
"detail":{"materials":["Failed to save option materials : None is not of type u' string'."]}}

When I try to patch an older model (few weeks old) I have to add the two disabled sss channels to each material manually. Once that's done I get an additional error:
"detail":{"background":["Failed to save option background : Additional properties are not allowed (u'enableVR' was unexpected)."]}}
Even though there's no "enableVR" property in the patch data.

Could you help me solve these issues?


(Shaderbytes) #54

by the looks of this thread it should be said that decent up to date documentation is required.. honestly people should not be playing guessing games or looking at network traffic etc


(Klaasnienhuis) #55

Well, it has been said the V2 API is deprecated, experimental and subject to frequent change!


(Shaderbytes) #56

true, but nothing stops them fro, doing the above.. even if they changed it everyday


(Shaderbytes) #57

its bad practice that is all.. a case of "nobody realy uses the api the same way we do, so we can just f%$%^&k it up as we please uutil somebody asks"


(Shaderbytes) #58

ok maybe not that bad , dont get all huffed and puffed ... but the dev team are irresponsible when it comes to making changes and keeping the documentation in check.. at lease they have version numbers :slight_smile: but saying something is depreciated means the new is fully functional and is ready to replace the said item.


(Shaderbytes) #59

i reported anerrror in the documentation concerning getNodeMap over 3 weeks ago and nobody has fixed it.
letsd hope second time lucky: here is the page:

https://sketchfab.com/developers/viewer/functions#api-getSceneGraph

the line

"This function provides the scene graph. The callback will be passed ( graph )."

is incrorrect it shoul be two arguments :

"This function provides the scene graph. The callback will be passed (err, graph )."


(Klaasnienhuis) #60

By the way @stephomi and @tribble42, here's the code to reproduce this issue. Please use a scene with 1 material as this code only nullifies the matcap texture reference to the first material. I'm patching back the original data which should not give me any errors. But it appears there's some invisible material property causing errors.

var uid = 'scene-with-1-material';
var token = 'get-your-own-token';

var xhrGet = new XMLHttpRequest();
xhrGet.open('GET', 'https://api.sketchfab.com/i/models/' + uid);
xhrGet.send();
xhrGet.onload = function() {
  var xhrPatch = new XMLHttpRequest();

  xhrPatch.open('PATCH', 'https://api.sketchfab.com/v2/models/' + uid + '?token=' + token);

  xhrPatch.onload = function() {
    console.log(xhrPatch.responseText);
  };

  var result = JSON.parse(xhrGet.responseText);
  var opt = {
    options: result.options        
  };

  //disable the matcap texture reference on the material
  var mtlName = Object.keys(opt.options.materials)[0];
  var mtl = opt.options.materials[mtlName];
  mtl.channels.Matcap.texture.uid = null
  
  var str = JSON.stringify(opt);

  xhrPatch.setRequestHeader("Content-type","application/json");
  xhrPatch.send(str);
};

This results in
{"detail":{"materials":["Failed to save option materials : None is not of type u'string'."]}}
When looking at the model data, I'm not seeing where I can tweak the results to go around this.

If you don't work around the matcap issue for each material you'll get:
{"detail":{"materials":["Texture(s) with uid 35c4d334eded44d8a657f390954a32dd doesn't exist."]}}
But like I said, this issue can now be worked around with the code in the sample above