Suggestion: auto save canvas screenshot in .gh file

Grasshopper
1

I just opened an older setup of mine which made use of some outdated firefly version and grasshopper kicked out the bitmap sampler nodes.

now I am pretty lost after not having edited these in 2 years as the connections are gone and it is hard to trace back what got broken. doable but time intensive.

this is the message i get:

2016-11-10 22_01_21-Grasshopper Archive Messages.png739×575 31.8 KB

If I had taken a screenshot of the original I would be able to repair things within minutes.

I just tried the export high res image with a large setup and it saved a 14k .jpg within 10 sec. on my 2010 core duo laptop. If that could be an automatic option to be embedded right in the .gh file, it would help with plug-in related errors.

just curious, maybe there is already some possibility of auto executing export high res image upon grasshopper exit, for all open documents?

besides that I am wondering if there is any way to list the nodes that were connected to the removed ones?

cheers,
daniel

2

I’ve always thought that it would have been best if some placeholder objects were inserted in lieu of missing plugin objects. As long as the missing object is a standard component/parameter, the connection data can still be harvested by Grasshopper. I never got around to implementing this, but would that sound like a better solution?

3

by standard component/parameter you mean native grasshopper elements or any plugin elements as long as they are not custom scripted?

I mostly had the problem plugin related, old native grasshopper nodes usually display “old” but still show up and run fine.

From the graphic user point of view I think a dumb dummy object that is a simply a square holding the in and outputs would be sufficient, as one can visually it trace back.
I have no idea how this information is handled or saved inside the file, but if just the “node box & wires” could be re plotted as they were in the last file open it would be a solution too.

so yes, I think your suggestion is a better solution if it can work across nodes coming from plugins as well.

still thinking about the auto image export though, could you potentially export the nodegraph as vector pdf?
that would be pretty cool, as you could at least browse it on a smartphone/tablet compared to a 14k bitmap, and that would keep the total filesize very low too.

4

I mean any component which derives from the abstract base class in Grasshopper core. This includes almost all components everywhere. Some examples of native objects that do not inherit from either the base component or base parameter are:

  • Jump objects
  • Galapagos
  • Scribbles
  • Groups

Even exotic stuff like Pie charts, Gradients, Image Samplers, Clocks and Calendars would be covered.

5

@DavidRutten Wouldn’t you be able to lash up the right legacy configuration to recover the key data for Daniel? Or have you thrown out all that old stuff?
I’ll bet this sort of thing happens more than once; it would be good if there was some central repository of readers for every version of GH right back to the beginning.
Going forward, Daniel’s idea sounds pretty good.

6

sounds like you have a plan David

concerning the unsupported object types,
I can’t determine how likely it is that one of these gets corrupted/wrongly interpreted/skipped etc. I mean why would a scribble object not load ?

As I understood my case firefly was causing the problem.
or some shortcoming in the plugin version management having to do with not being able to replace the bitmap sampler nodes although they were still working in the same manner.

to me it sounds like it will need some work to get this functionality running and probably some adjustments when new plugins/extensions are coming out, that is my limited user POV.
if it is easier to make a “shift+ctrl+s” save including the canvas bitmap, I would not mind it either.

@AIW
i had problems with uninstalling a certain firefly version and it kept me from trying to restore the old config, not wanting to mess up my machine again.

I am a classic workstation user, but in such a case virtual machines would be an excellent help.
It is just something I usually do not need as I don’t code an do not need to simulate different environments… and I never felt the need do dig into the subject.

but sure, that file is from april 2014, if someone has a snapshot i am happy to send it over :grinning:

7

I was just thinking that David himself might be in a position to (relatively) easily recover your data.

8

It’s very unlikely that an object gets corrupted inside a gh file. If corruption occurs it’ll in all likelihood render the entire file corrupt as the files is a compressed byte-array, and it cannot be successfully decompressed if even a single byte is out of place.

There are four ways in which objects might fail to load:

  1. The object is defined by a plug-in which is not loaded.
  2. The plug-in which ‘owns’ the object is loaded but is an older version than the one loaded when the file was saved and the object has changed in a non-forward-compatible way.
  3. The plugin which ‘owns’ the object is loaded but has changed the way the object is (de)serialized and the developer hasn’t taken the appropriate steps to make sure older files still work.
  4. The code which (de)serializes the object is just buggy. It somehow fails to write the correct data it requires upon reading. A bug like this most likely only happens for particular states, otherwise the developer would have found the problem during even the most cursory test cycle.

(1) is obviously quite common, but also fixable without help from the developer. Just install the missing plug-in and you’re on your way (don’t save the file after loading fails, or relevant data will be lost)

(2) is also reasonably easy to fix, assuming you can upgrade to the newer version.

(3) is a bug and can only be fixed by the developer. Breaking backwards compatibility is easy if you’re not careful and it does happen.

(4) is a bug and needs to be fixed by the developer.

It is easy to embed the canvas as a bitmap inside the GH file. I already include a thumbnail, and it sounds like you’re just asking for a bigger version of that same image. I do not however think it a good solution. The canvas may only show part of the file, omitting something relevant. I could of course render the file to a large off-screen bitmap, but some *.gh files can cover lots of pixels, I quite often see files with individual objects way off in the distance, far away from other components. Should I include a 15,000x29,000 png file which contains 99% empty background grid?

The solution I’m planning (no idea yet whether it’ll work as well as I hope) is to parse as much information as possible from an object which fails to load via the correct channels. If I can get position, size, parameter types and names, maybe even parameter properties (flatten, simplify, expressions), I can create a placeholder component which doesn’t have any functionality but which does retain all connections, and can even maintain the actual file data, meaning that when the file is saved, the data that was not understood during loading isn’t actually lost.