Model rejected for not outputting geometry


The model I’m trying to upload is being rejected by the server for not outputting geometry. But this very same model was accepted for verification yesterday and it does output geometry. I’m using a JSON file uploaded to a remote server as a text input, no rhino geometry is used. I’ve checked that the file is accessible, and of course it works on my GH, so I’m not sure where the problem is.

Best (37.4 KB)

Hi Filipe
Please check out the ShapeDiver Documentation: Model checking – ShapeDiver - Documentation and Support

If no geometry appears to be displayed in the viewer, the model will be denied. This check was created because many users forgot to turn on the preview for the desired components, or to use the display components of Grasshopper (Custom Preview) and the ShapeDiver plugin.

Hello @praneet

Could please check the gh file on your machine. It is displaying geometry on my end. It actually has multiple geometry outputs. I’ll try to add something else to debug it on the server.

Problem found. The ShapeDiverTextfileInput component is not fetching the file from the URL. If I try to upload a JSON file on ShapeDiver platform I get an error saying “this component is currently inactive”.

You can check on the gh file above that I set the TextfileInput to just allow JSON. On grasshopper this is returning a warning that ASCII format was used, while the JSON file was specifically saved with UTF8. Not sure if this is related.

Another important detail is that there is a C# component on the model but the server didn’t pick it up for checking…probably because the textfileinput fails in the first place?

Whenever a script has been validated, it doesn’t need to go through this step in further uploads.

Thanks @pavol, I wasn’t aware of this, but it still doesn’t work. The ShapeDiverTextfileInput works perfectly fine with the JSON file I’m using in Grasshopper but not on the platform. What is the problem? Stricter encoding enforcing?

I don’t think the problem comes from the text file input. Which version of Rhino are you using? When I open your definition in Rhino 6, a C# component throws an error:

It looks like the function you are trying to use (Rhino.Runtime.CommonObject.FromJSON) does not exist in Rhino 6. I opened the definition in Rhino 7 and it looks like the function exists there (although I then get a problem with jSwan but that’s probably my setup).

Our shared servers run Rhino 6 at the moment, so if you are using Rhino 7 specific features it will not work. You can request an access to the Rhino 7 system if you are interested, or try to bypass this FromJSON function with another method.

Thanks @mathieu1 for looking into the problem. I’m using Rhino7 and I wasn’t aware of that this method was specific to it. I’ll try to come up with a solution that works both in Rhino 6 and Rhino 7. I’m using this method because in rhino3dm.js there is a built in ToJSON method. The problem is that it encodes the geometry in a Base64 string. This is a good thing for sending large objects across the web but this encode method is also not available on Rhino6.
I see no option but to build a custom JSON object. If you have a simpler solution, please let me know.

I am not sure what you are trying to do but this might help: most of the geometry types are supported by the Data Output component and will be converted to JSON objects in the viewer. For example, if you connect a nurbs curve to the data output:

The viewer will give you a json representation of the curve:

Hope that helps.

I’m preparing a function that creates a JSON object, which contains a polyline and a list of lengths. I’m trying to create a workflow that is as code free as possible on the Grasshopper side and takes this JSON object to use it with my plugin RoomSurveyor.

This is what I’m planning now:

It is working now. Thanks!