We are using the backend API to generate 3D geometry and a JSON file, which we then use in other processes.
During generation we often get errors that are not quite clear what they mean and where they come from. Our file works in like 95% of cases, but some parameter combinations seem to just fail (even though they work when trying locally).
What I don’t understand in the response from Shapediver’s API is that a lot of inputs have a not that says “This component is currently inactive”, even though nothing in the GH file is disabled.
"Sorry, no data to be exported for these parameter settings” means that the export request was successful but there was just no data to be exported so you might need to review your Grasshopper definition for edge cases.
The note for parameters doesn’t have any influence on the functioning of the model. The value which gets set for note on the current live version of the geometry backend doesn’t make sense it most cases. With the new geometry backend the note will become a tooltip and the messages will be clearer.
One thing we noticed that might be a source of an error is around decimal places. Is it possible that Shapediver doesn’t round values?
Say I have an input parameter and in GH it is defined as having 1 decimal place and then using the backend API we send a value to the model with 2 decimal places and it seems like that is causing errors. How does Shapediver handle these mismatches?
We get this return and no file is produced. Any idea why that might happen? Seems to be something around the export cache?
ps: I should note that all recent errors are around exporting the JSON file, which we only need since you can’t get parameters directly through the API like you can in the frontend API using api.parameters.get();. I know its already suggested in your backlog, but it’s a really important one and getting back parameters is like one of the main uses for Shapediver in the first place.
@seltzdesign the delay property tells you that computation of the solution has not been finished yet, and your application should wait for delay amount of milliseconds before sending an export cache request.
I didn’t understand this, please explain in detail what it is that you are missing:
I mean that I want to be able to retrieve output parameters through the backend API. I was told before that this was never implemented and only works in the frontend API at the moment. What it means is that if we want to retrieve output parameters we have to create a JSON file and download it and read the parameters from there.
At the moment the JSON file download is not working in any of our old versions even though it was working fine before. Did you change anything about the way the JSON file download works on Shapediver?
Whenever we try to download the JSON file we get this error:
There must be a misunderstanding, please let me know what exactly you are referring to by “retrieve output parameters”.
Do you mean the values you are setting for the (input) parameters of your model?
Do you mean the resulting values of data outputs of your model?
No changes have been done.
The content property of response.data is optional, it will not be set in case the export failed for whatever reason (or, if you are using the backend API, if the export is not finished yet). Please make sure your implementation deals with this case. Corresponding documentation related to export results for our viewer’s API: ShapeDiver 3D Viewer Interface: ApiExportInterface
In case you can’t figure out the problem, please provide an easily reproducible example:
I mean the parameters/values that you can output from a Grasshopper script and can read with the frontend API. It seems that you cannot do that with the backend API and I don’t understand the reasoning behind that. I was told a while ago that it was simply not implemented yet. That was a few months ago and I would have thought it’s not that difficult to add that functionality that you have in the frontend API also in the backend API. Having to use the export interface just to get a bunch of values and strings seems like the wrong approach for this. There should be a more direct way of getting output values where you directly get the JSON response. I have seen no other API that takes that detour of having to download a .json file and then read that file for the data. It would be like me typing this response in Word and then attaching a word file to an empty comment on here - it just doesn’t make sense.
Can you explain this in more detail. This is the response we are getting to the initial export request after X seconds.
Can you tell us why this error is occurring? What exactly is happening too soon? Doesn’t the respond from Shapediver just come once it is done?
So if I understand correctly, we send an export request. After some time the export is not done yet, but Shapediver already sends a response saying it will take some longer. Then after 1 second we send the request again? I don’t understand what it is we have to do to fix this?
Does it relate to the max. calculation time of 10 seconds?
It’s of course possible to do that, since always, after all this is the API our viewer is using to do exactly that. We have on purpose not published documentation about this and announced this feature yet, because we do not consider it simple enough to use yet.
It’s not an error but a feature. This thread is not the right format to discuss the reasoning behind the design of the ShapeDiver Backend API, we can have a separate discussion about that. Therefore I suggest to reset this discussion to the following, in order to arrive at a conclusion which will solve your issue:
Sure, I also don’t want to make this into too big a thing. We are exclusively using the backend API to generate 3D Models and to generate some output data like sizes.
Everything is triggered from and gets saved to Ninox. Currently we are also using Integromat to download and read the JSON file and then save it to Ninox, since this is currently the only way to get the output data. We are using a Webhook to request the exports.
If we can directly get the data in a response that would make things much easier. I think we still need Integromat since for the file export you only have a temporary link, so we need to grab the link, download the file and put it on our own storage. It would be great here if there was something like an “Export to” option, so we can just have a download save to our own Amazon S3 storage and get the URL to that instead of the temporary one from you. Alternatively, it would be nice to just have persistent links and we pay something extra for the storage.
I don’t need any reasoning. I am sure there are very good reasons it is built the way it is, I just want to understand what it actually means. Why is a response sent before the calculation is done if normally the response is sent only when it is done? Does it mean the calculation has taken longer than some threshold, so that a response needs to be sent to notify that it will take longer.
So if I understand correctly, if we get a response with a delay in it, we should wait the delay and send the same export request again?
We are thinking about adding such a feature, however you would have to allow public uploads to your bucket, or pass a so-called pre-signed S3 url as a parameter value (the pre-signed url would have to allow the upload for a limited amount of time).
Are you aware that these links would be publicly accessible?
That’s correct. In this case you just send the same export request after waiting for at least delay milliseconds. Actually it would be sufficient to send an export cache request, but it’s easier for you to just send the original export request again.