Breach the "Bake gap"!

Replies to This Discussion

Permalink Reply by Luis Fraguada on September 20, 2009 at 8:22am

Yes it is possible with a scripting component.

Permalink Reply by Vicente Soler on September 20, 2009 at 8:33am

yes (no need for the timer component), but unfortunately the new referenced geometry won't generate realtime updates when modified.

Permalink Reply by Theunis du Toit on September 20, 2009 at 8:40am

Interesting, that would kind of defy the puspose I guess. Thanks for the answers guys.

Permalink Reply by David Rutten on September 20, 2009 at 10:36am

Auto-baking is not a logical impossibility. It would be fairly easy to add a feature which baked the result of a component, store all the GUIDs, and remove those objects just before the next auto-bake kicks in.

However, there are some considerations to take into account. (I'd love your input on this btw, which are important? annoying? irrelevant?)

- Interacting with the document means flooding the undo/redo buffers. If you start to autobake a serious amount of objects, you can expect to loose a lot of undo data that falls off the far edge.

- Changes made to a baked object cannot be reverse-engineered back into the Grasshopper definition. Whenever you bake something it will either override or replace the previously baked object. I might be able to not delete objects if they have been tampered with, but I'm not sure this is a useful feature.

- Geometry in the document can either be added or replaced. In practical terms this means I can either delete all the previous baked objects and add a bunch of new ones, OR I can keep the existing objects and only replace the geometry inside them. The latter approach requires less Undo data and allows you to maintain attributes (layer, colour, material, grouping etc.) between multiple auto-bake sessions. However, it is very difficult to decide what ought to happen if the AMOUNT of auto-baked objects changes. Which should get replaced/deleted?

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Theunis du Toit on September 20, 2009 at 1:45pm

Interacting - The undo is a problem. If I wish to manipulate baked geometry which will remain manipulated (look at Changes paragraph to see why) and I then wish to undo a step I need the last step to be that manipulation, but as I understand you there will be multiple steps of Baking which means I need to undo untill I get to that manipulation. But I think the answer for this lies in your 3rd paragraph, keeping the existing objects and only replace the geometry inside them to minimize Undo steps.

Changes - "I might be able to not delete objects if they have been tampered with, but I'm not sure this is a useful feature." - I think it will be a usefull feature. In my opinion even necessary but only SOMETIMES wished for, sugesting a True/False Boolean option. For exapmple, with Boolean set to True I will be aware that my untouched geometry will be replaced but that doesn't matter to me since it will remain the same and the geometry I have manipulated for a purpose will remain changed as well and my efforts will not be lost. After I decide I don't care about my manipulated geometry anymore and I want it back to its original state as the definition will build it I merely set Boolean to False.

Geometry - As I mentioned above it is beneficial to the undo process to replace geometry in existing objects instead of deleting all the previous baked objects and add a bunch of new ones. Now, if the AMOUNT of auto baked objects changes it can maybe be solved by the same True/False Boolean setting as in the paragraph “changes”.

To summarize:

Firstly, geometry in an object should be replaced to benefit Undo processes and maintain attributes. (layer, colour, material, grouping etc.)

Secondly, if you have Boolean set to “True” then manipulated geometry will remain the same while auto baking happens.

But if you have Boolean set to “False” then your manipulated geometry will be deleted all together.

Thirdly, when the amount of objects changes and Boolean is set to “True” the geometry is replaced not deleted to maintain attributes.

But if the Boolean is set to “False” all the previous objects are deleted and a bunch of new ones are added.

I hope that makes sense or is helpful. I probably missed some logical problems.

Permalink Reply by Theunis du Toit on September 20, 2009 at 1:48pm

By the way, can auto baking help solve the problem with a kind of basic loop in GH?

Permalink Reply by David Rutten on September 20, 2009 at 5:16pm

No, these are separate issues. Looping in GH is essentially an Interface problem.

Permalink Reply by Suryansh Chandra on September 20, 2009 at 10:01pm

Autobaking + instant re-reffering is certainly possible, only that you need to bake the object with a name, that you can then recall through the note component with the name of the object typed into it and the output of that plugged straight into wherever you need that geometry. But then this will also require the timer component to refresh your canvas so that it keeps checking for an object in Rhino with the specified name every few seconds.

Only that you need a few lines of code to bake geometry with a preset name. Once baked, you can manipulate it the way you want, and since this is now the input into another part of your definition, all manipulations to this object will affect the output and keep the connections 'alive'.

I often use this technique to make graphs out of crvs in Rhino, as the Graph component in GH only offers a very limited capability to manually tweak the curve. So I can keep changing the curve, and the crv XY is interpolated as a graph into GH.

To give some feedback to David, I think baking+replacing is perhaps a more effective way of dealing with Geometry as compared to the current 'preview' system, because at any instance, you can do manual operations with it like snapping other objects to it, or render it, or just manually manipulate it.

The current display system somewhat overrides the native Rhino objects in any display mode, shaded/rendered/ghosted, and when one is dealing with a large amount of geometries or complex shapes, the red/green translucence becomes a bit hard to deal with. Also, if one is dealing with surfaces of acute curvature, the display often shows up as optimized low polygonal mesh display instead of the native Rhino 'smooth + slower' display -- which can require frequent baking to really know where the surface is. So then, out of lack of choice, one either resorts to a 'custom preview' which makes them opaque, and shows the geometry a lot better, but is computationally extremely intensive (especially if the colours are all different (say analytically) - imagine simple things like curvature analysis of a building facade with 2000 panels, each with a different colour). So then comes baking to the rescue -- just because it hides/shades/renders perfectly and precisely.

If the autobake+autoreplace is given a serious consideration to replace previewing, it could perhaps maintain associations in the manner implicit history does it -- that it stays 'alive' until a manual operation modifies it by moving/trimming/pulling/pushing/etc -- perhaps with a warning dialogue. Once that happens, GH could then create a new instance, which is alive.

Then baking would not need to be seperate issue, it would be as simple as manually modifying the object in the viewport. So unlike the implicit history, GH would not have to be 'listening' to Rhino commands, still remaining explicit, but would still maintain the parametric linkages to objects that are created.

David, I hope you can find the time to read all that :)

Permalink Reply by Sameer Kumar on September 21, 2009 at 8:40am

I have a related idea (at least to my mind) which may or may not be possible but I will share it in any case.

Last time I had used a software which had a "tree" view was Softimage back in the mid 90s. Every time one dropped an object in the design window, there would be added a tree-object in the tree-view window and vice-a-versa. Moreover, one could select an object in either of the views and it would highlight in the other. It was extremely useful to work with as one could initiate the model in either window and the two would remain in sync. I do concede however, that the tree view in Softimage was way less sophisticated. It only had object components (no actions) and the main purpose of the tree view was to set up parent-child relationships to assist in animations. The tree-view in our case, i.e. GH, is immensely different in what it does.

The point I am trying to make is that if it becomes possible for GH and Rhino to "share" objects as Suryansh states, it may open up other interface possibilities as well.

Being able to perform commands on objects in either of the windows with the other synchronizing automatically would be the holy grail, but I am not wishing for it. :)

Permalink Reply by Damien Alomar on September 21, 2009 at 4:33pm

Took a quick stab at this one using the ReplaceObject method, which is most likely the most efficient way to do this (very simple tracking down...no deleting/renaming mud to track through). Essentially, some "dummy" geometry is referenced into the GH definition through a GUID component. The actual geometry itself doesn't really matter, since it is connected to a VB component that will replace the object with the GUID in question.

There were several interesting things that came of this. First, referencing the actual geometry down the line posed an issue which Grasshopper. It spit back TONS of error messages about things within the solution expiring. So, this is NOT a good idea if you reference that object back into GH somewhere.

Second, you can, if need be, reference the geometry back in through the GUID component. This will prevent having the "expiring reference" issues that happen when you have the geometry referenced directly into GH. The only catch with this is that the GUID component will not "auto-update" with changes, since the GUID is still valid (this apparently is normal behavior). So, in order to get the geometry back into GH, you must then hook up a timer component to the GUID component to force a rebuilding of the solution.

Third, there's a LOT of events that are getting fired in this situation that Rhino has to keep track of, and potentially other plugins may be watching. This has the potential to really make things go crazy in certain circumstances. As far as I can tell, the Undo buffer doesn't seam to be too over whelmed, but since I haven't done too much testing with this I'd take it with a grain of salt. I hooked up a small plugin with some event watchers looking for when an object was replaced or added, and it was firing constantly when modifications were happening. If a plugin was actually watching for those same events, then it would likely cause a lot of work to be done, so again something to be aware of.

Lastly, use this definition with caution. As I said, there were a few issues that I saw with this situation, although they were specifically related to geometry references later on in the solution. I'd try it out in a limited situation first to see if it works how you need it. If you're using it on anything significant, I would save often.

HTH

Attachments:

• AutoBake_test.ghx, 71 KB

Permalink Reply by Vicente Soler on October 2, 2009 at 7:11am

If you connect a brep parameter instead of the ID parameter to the surface frames component there's no need for the timer. The spikes will update real-time when you move the sliders.

The only catch is that at some point you have to manually reference the modified object. It seems that you can't automate the entire process of creating geometry from GH, baking it and automatically reference it so that it updates when it's geometry is changed.

Permalink Reply by Damien Alomar on October 2, 2009 at 8:10am

Well, when I did that I got the following image popping up at me. GH doesn't like object changing once its started trying to solve the solution, which is exactly what the scripting component is doing. It may be completely okay to click the "Don't Show This Again" option, but ultimately, I think its a bit safer to just worry about expiring the GUID component

• ‹ Previous
• 1
• 2
• Next ›
• Page