I just uploaded a Grasshopper file to Shapediver and I can see all the inputs. But there is no geometry output at all as I can just see the shapediver logo.
How can I debug what is going on? Of course locally it works fine and there is a mesh that is going to the SDDisplayGeometry node:
How can I debug this? I have tried the api.debug method in the console, but it doesn’t give any information!?
Use the api.scene.get(null,"CommPlugin_1") call to see if all assets you expect have been loaded to the viewer.
But judging from the screenshot, you send quite dense mesh to render which might cause this issue. I would recommend to make a low poly mesh for rendering and separate the production mesh logic with a toggle. Lighter rendering mesh will also make your model more responsive.
It might be worth checking that the curves you get from text for extrusions are polylines with reasonable number of points. More on the subject here:
You can also try our LoftMesh component for efficient mesh creation. See more here:
Hi @pavol.
Thanks for the suggestions. Actually all the input parameters are there. There are around 10 or so parameters with internalised data. But they should all be there.
We are not using Squid at all (because it didn’t work so well), so all the character outlines are actually just NURBS curves and we have built our own kerning of the letters and so on.
Yes, the Mesh is probably finer than it needs to be, so I will try it with less quality and maybe without the bevelled edges.
It would be nice if it would give an error message in that case though.
Okay, after a lot of debugging I think I found the reason:
You can’t internalise Groups.
I had to ungroup all our geometry > put into a geometry parameter > internalise > group them again.
Anybody know why you can’t internalise groups?
Support for groups is coming soon.
Okay, interesting.
Weirdly I was not outputting any groups. We use groups for the curves that lead to the extrusion, but the output is actually just a single mesh. But it seems then, that internalised groups are also not supported!?
You can have internalised group in the definition, it won’t be displayed but the model will work, I just tested it. I’m not sure what’s happening in your model so feel free to share a minimal definition reproducing the issue.
On a more general level, groups are not the best for managing the data in Grasshopper and we encourage our users to keep geometry in trees. Check these tutorials for more:
Hm, yes that IS weird then. It must be another bug then. For some reason I had the internalised groups go into a transform component and it had just some move transforms going in. The output of the transform was all NULLs. It seems to work better now with the geometry internalised ungrouped.
Yes, I am doing the grouping very conciously. Since we already have a data structure of 2 levels even with the groups, we are just trying to keep it manageable. It’s very difficult in GH once you start going over 2 levels of hierarchy, as you have to start duplicating all your transforms and so on. With groups at least it stays manageable. Its the drawback of not having any looping in Shapediver, your data structures have to become much more intricate. But its not really a shapediver issue, it doesn’t make sense until Grasshopper supports it natively.
Now we have hit another roadblock though. I am now displaying the mesh using just the “speed” settings for MeshBrep. But we actually want to output the file for the 3D print, which has to be very high quality. With longer word combinations the computation time of 10s simply isnt enough on your servers. On my computer it calculates the long text in 3.3s though. I have reduced the quality slightly now and then it can just about do it on Shapediver, while locally it executes in 2.2s. I have a i7 9700k, so it seems that the servers you use are quite a bit slower than that (single core). But I would assume that you are using Amazon EC2 as well!?
So it looks like we need to either extend the limit, but which would mean going to the Enterprise account, right? Or we just switch over to Rhino compute and set up our own server on Amazon EC2 and use that, since we only need backend API access anyways and don’t need the viewer or UI elements. I think its a matter of cost in the end and if we can somehow work around the (time) limitations of Shapediver.
The best practices for building parametric online apps including meshing strategies are well covered in the webinar series. Computation time on your desktop will always vary from the cloud, more in this article:
We can offer you extra computation time up to 30 seconds with your PRO account, custom server set up is available to Enterprise customers. Contact sales through the contact form at www.shapediver.com if you are interested.
Rhino.Compute is definitely a powerful service and it might better suit your needs if you prefer to code your own applications and get involved in set up of your own cloud infrastructure. I would be interested to hear about your experience.
Thank you for that, some interesting info on there. Actually the last paragraph on “Advanced Use Cases” is already what this is. This will only be a backend API process called after an order is placed.
Okay, that sounds like it could work. I will write to you personally regarding that. Saying that I have now reduced the mesh quality to where I think it still has no visible facets during 3D printing even at large sizes and it seems to be calculating in under 10s for most inputs now.
For sure. We just want to try it out anyways and see how far we can go with it. Digging into it a little bit I can definitely see that quite a lot of work has gone into Shapediver! You don’t really appreciate it until you try to build your own 
But we are going to try it out anyways locally at first and then maybe using Amazon.
