Losing Internalised Data

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.

//Frans

Replies to This Discussion

Permalink Reply by David Rutten on February 12, 2014 at 9:26am

Hi Frans,

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

David Rutten

david@mcneel.com

Permalink Reply by Frans Magnusson on February 13, 2014 at 2:09am

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

Frans

Permalink Reply by David Rutten on February 14, 2014 at 2:16pm

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

david@mcneel.com

Permalink Reply by Frans Magnusson on February 17, 2014 at 2:37am

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

/fr

Permalink Reply by Vicente Soler on February 20, 2014 at 7:46am

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

Attachments:

internalizederror.gh, 3 KB

Permalink Reply by Carl Christofferson on March 12, 2014 at 7:40pm

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.

/Carl

Permalink Reply by David Rutten on March 13, 2014 at 3:09am

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

David Rutten

david@mcneel.com

Permalink Reply by Carl Christofferson on March 13, 2014 at 9:08pm

Oh, still using .69

Will update!

Permalink Reply by FRiou on July 23, 2014 at 8:00am

Hello,

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?

Thanks.

Flo

Permalink Reply by Steven Janssen on July 28, 2014 at 2:10am

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.
Steven

Permalink Reply by peter fotiadis on August 1, 2014 at 12:57am

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):

http://www.grasshopper3d.com/forum/topics/kangaroo-matters-relaxing...

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

Note:

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":

Attachments:

Relax_panels_on_nurbs_V3-INTERNALIZE.gh, 643 KB

Permalink Reply by peter fotiadis on August 1, 2014 at 1:14am

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?