Having trouble uploading a Grasshopper definition - I am just getting a generic error message - is this due to computation time?
Your model doesn’t pass the model checking due to Text Curves from Squid. The component doesn’t work reliably with some fonts so here is an alternative solution for you. First, convert the font you use to meshes with MeshGrammarMaker.ghx. Then internalise the result and use it as input for MeshGrammarConverter.ghx (454.5 KB) which will replace the Squid components in your main definition.
This is also more efficient than generating curves from text every time the model runs. Let me know if this works for you.
1 Like
Oh, great, I didn’t realize the component had been forbidden.
This seems at first sight to also be a workaround to your font list limitation as long as all of the geometry is internalised, is that correct?
Thanks!
The component itself isn’t forbidden, it just sometimes causes trouble and we are investigating what exactly is the issue.
And yes, as long as the characters are converted to meshes and internalised this should work.
I replaced all instances of the Squid Text Curve Component and replaced them with the mesh grammar converting, but I am still getting a generic error message:
Ref: d0001613-50f9-46f9-b209-d0c9c9b9f11f
I’m not sure if it is a related issue or separate, thanks for your help!
My apologies for the inconvenience, at least you improved performance of your definition with meshing fonts. Could you please make sure:
- the display outputs are within the limit
- there are no
Nullor invalid items in display input, just add Clean Tree component before SD Display (we will make the component more robust and able to handle this soon) - there are no
Nullor invalid items as internalised geometry and the definition doesn’t exceed 10mb
Let me know if you still get errors and post your definition, I’ll have a closer look.
1 Like
I’m following this as I’m having the same problem.
Didn’t you say that Null’s are not a problem in general?
Will definitely check my model for Nulls now 
I’m trying to figure out the root cause for the same undefined error which only occured after the latest Shapediver viewer update (around May 4, I think) on a model, that uploaded fine just before that update. Exact same model, no changes in between.
Yes, I did and sadly, I might have been wrong. 
Thank you for pointing it out, it seems something slipped through the net when we were testing. We will make sure that Nulls won’t be a problem ever again!
1 Like
I’m actually glad I might have another lead to solving this mystery.
Will provide feedback if this has solved the issue for me.
I had an invalid item, so using Clean Tree before the SD Display solved the issue. I am now able to upload.
However, I seem to now be having an entirely different issue where my text is showing up in the wrong place (see Rhino Screenshot vs. Shapediver). Is there any chance that the “loc” / plane input on the C# Grammar Converter might be malfunctioning when inputting planes from “Align Plane” components? Any troubleshooting tips?
I created a condensed version of the script attached here with internalised planes and text, but it does not reproduce the error. gedcom-parsing_condensed.gh (258.7 KB)
Here is the shapediver operating correctly with internalised data:
https://app.shapediver.com/m/gedcom-parser-condensed-internalised-data
And here is the malfunctioning model:
https://app.shapediver.com/m/gedcom-parser-treepress-multi-generation-5
I just tested the Mesh Grammar Converter with input planes from Align Plane component but I couldn’t reproduce the issue. Could you post your original definition which doesn’t work as expected in ShapeDiver?
Thanks. I tested whether the same problem occurred with text tags an alternate C# script, and connecting the planes to circles instead of a text component; all three reproduced the issue, so I have not been able to isolate it. I am attaching the original script, I’ve put what I think would be the relevant portions to the left of the canvas, with outputs on top. There is a lot going on in there terms of text processing and data handling, but the final transformations and positioning of items is fairly basic. gedcom-parsing_sd-forum.gh (777.3 KB)
Some Grasshopper components give reliable results but in a somewhat unreliable order if one is not careful with the data structure. This is especially true in the case of splitting and joining components. For example, in this part of your definition:
It is a little risky to flatten the input curves of the “Join” component. Depending on the machine used to compute the solution, the output curves can be given in a different order. This is what happened in your case. If you flatten the output curves instead, the problem is solved.
gedcom-parsing_sd-forum SD.gh (803.4 KB)
In your definition, the input curves are organized in a tree, which makes it simple to solve the issue. However, it is not always possible. In most cases, it is good to do some sanity checks after those components to make sure the data is organized as you expect it to be.
This type of issues was discussed by Edwin during our recent webinar. You can catch up on the webinar on our youtube channel. We already uploaded the recording of Day 1.
Thanks, Mathieu, it wasn’t happening in a prior version, that solved the issue!