algorithmic modeling for Rhino


I am constantly losing internalised geometry data. Am I doing something wrong or is this feature still not to be trusted - in that case what is the plans for it. I believe it is a great thing, but it needs more stability.


Views: 2808

Replies to This Discussion

Hi Frans,

which version of GH and what sort of data is getting lost? Numbers, Breps, Meshes, Curves?


David Rutten

Hi David

This last incident happened with 0070 and a polyline.

Generally we have had issues with geometry disappearing since the feature appeared.

Best wishes


There was a bug on Rhino4 with this feature, causing data to be written to a file, but failed to read back in. As far as I know this was fixed in Rhino5, but maybe it's still an issue.

If you have a file that is supposed to have internalized data that isn't there on opening, please do not save the file again but e-mail it to me. As I have no way at present to reproduce the bug we need to start figuring out whether it's a problem with reading the file or writing the file.

Incidentally, does the data go missing on the same computer, or is the file written by a newer version of Rhino and then fails to open properly on an older one?


David Rutten

i will get back to you if I find a specimen.


The B input should have a "2" internalized. This bug happens very frequently.


I have the same issue with losing internalised data. I often internalise numbers into the math operator components and sometimes they will suddenly dissapear. This happens when saving and opening files on my own machine, as well as when saving a (functioning) file and opening it later on another computer.


Have you seen this problem with the latest version? I fixed at least one bug in 0.9.0072


David Rutten

Oh, still using .69

Will update!


I had the same issue with GH 0.9.0069, but even after updating to the lastest version of GH (0.9.0075), it remains.

After extruding two different profiles, I internalize the resulting Breps into two different parameters.

Strangely, after reopening my file, some Breps are lost and not the others (see capture attached).

The tree structure is maintained but every Brep is replaced with a Null element.

Have you found a solution to this problem? Does it have something to do with the "complexity" of the geometry (the lost Breps are more complex than the ones that are correctly internalized)?

Is there a workaround, apart from baking these Breps into the model and reintegrating them into the GH file?



Yep, I also have this problem. I was internalising some breps which represent the milling spindle that our robot holds and reopening files it would sometimes disappear, or else still be referenced, but say "null" in the input parameter. More perplexing; I would often have a bunch of breps internalised within a brep parameter, but only some of them would disappear. Let me know if you need a file to have a look at and I'll try to dig one up. My guess is that the problem lies on the saving end, as I can usually open up an older version of the file and recover the component.

Well ...

... this lost internalized data issue is the norm here in Greece (using the latest and greatest GH build etc etc).

For the latest original case (and the Rhino file):

For a simplified version of the lost data issue use the modified  def attached.


1. In this case GH stored some data (3 out of 5 nurbs). Notice that the internalized info is dimmed (but "null" is the final output).

2. Image sampler suffers as well - here using a recent photo of me (+ my cat) as a test ("save in file = on" it doesn't work in pretty much all the cases).

If the sampler could work you should see this:

3. Imagine storing captured images in various directories and creating a GH def using some images from, say, directory "capture screens 17".

In some occasions Image sampler stores correctly the image file name ... but mess things as regards the donor directory:

Here's a typical example with image files stored and directory name "replaced":


BTW: The odd thing (use the original def in the link provided above) is that GH can internalize all the times some type of data like this very simple planar surface used as "template" (this is never lost no matter how many times the def is opened/renamed/reopened/changed etc etc). Maybe an issue related with the complexity of the data in question?






  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service