Exported .obj not compatible with Input-component?

Grasshopper ShapeDiver
1

When I try to load an .obj-file that was exported via the SDExportDownload component,
back into another document via the SDGeometryInput component, I get this error:

  1. File format application/x-tgif denied, accepted formats: application/dxf,application/wavefront-obj,application/x-autocad,application/x-dxf,drawing/x-dxf,image/vnd.dxf,image/x-autocad,image/x-dxf,zz-application/zz-winassoc-dxf

Does that mean the exported .obj is not compatible with the import-component?

2

I didn’t manage to replicate the problem and more information would help to get to the bottom of this. Could you share a minimal, simplified version of your Grasshopper definition?

3

Hi Pavol, thank you for looking into this.

It turned out to be a CORS (Cross Origin) issue on closer inspection, so it was not the exported .obj that was wrong or a failing input component, sorry for that.

It would be great if you can properly configure the files on your end though:

  • Allowed Origin: *
  • add the correct metadata to your URL file with Content-Type = application/octet-stream
  • if the file is compressed Content-Encoding = gzip
4

@shwdehaan when you experienced the problem, how had you been serving the obj to the geometry input component? I suppose you used dropbox, or did you make it available using some webhosting? Please explain.
CORS can’t have been the problem, it does not apply when our geometry import component accesses the obj via a url. CORS only applies when sharing resources with browsers.

5

Hi @snabela,

Here’s some more in depth explanation about what we’re doing here. Hope that’ll make clear what the problem is.
On our backend we’re first fetching the model data (using the backend-ticket).
Then we’re firing an export request with a some tweaked parameters.
The url of the file export is being made available, looking something like: https://sdeuc1.eu-central-1.shapediver.com/session/7a1a627f-6fec-41f5-975c-601fa18a742d/export/9c4be01d1bcf17290e69c9122fb0cf86f033f27cf08fe429afba017341230cd21b4c48ed700da608074bb1e84e64da00bdaa3e6ac743b6c6efc93d0e779a371e1665d8ae82c6783e9672b8dfbe235e96e902a631739ca7eff66ee442937633f0ecffd22900b728156728300db578f5356385542a2971885eb8680ea8a27bd41d43ab76f46c9014f520f5584d3ff4970921e22c416c0afe0c6361ae1facd2b73c31e5921c7416130a0991f1a6d9b107c6-37613161363237662d366665632d3431 (this one has expired)

We’re then fetching data of another model which can generate/export .step data. We’re requesting an export which works fine when sending an .obj file from dropbox as “file_url” parameter. I did another test by hosting an .obj file at DigitalOcean Spaces. Here the Content-Type = application/octet-stream metadata was key to get it to work. So our conclusion is that for the above url/file you provide, this specific metadata is not being set.

Hope this will help.

6

Hi @post8,

many thanks for your detailed feedback. I am not 100% sure whether I understood correctly what led to the problem you were experiencing, please let me know whether the following sentence is correct:
The problem occurred when you were feeding the export result url exposed by our backend API (https://sdeuc1.eu-central-1.shapediver.com/session/…) directly as “file_url” parameter to a SDGeometryInput component in your other model.
Is this correct?

We set the Content-Type of export result urls based on the file format which is fed into the SDExportDownload component, and application/x-tgif is not a Content-Type that would be reported by our backend API.

However the export result url for obj files includes a Content-Encoding: gzip header (because it makes sense to store and transfer obj files compressed), which is likely not understood by the SDGeometryInput component (to be verified).