The necessity for a data tree manager

Well friends

This thread (a bit weird and/or iconoclastic, mind) follows a very interesting discussion with Jon Mirtschin about what could be an ideal "next step" visual (so to speak) Data Tree Manager.

Jon has already done some very interesting stuff with regard decomposing matters using IFC schema (I'm not a strong admirer of any schema policy mind - for a variety of reasons).

Now the chaotic case:

1. This is deliberately fuzzy, faulty and chaotic in order to indicate the need (at least IMHO) for a next step with regard handling and visualizing (on a per individual data item basis, not on a per branch basis) data trees.

2. Why this Tree Manager future thing could boost GH up to an unseen level? Exploit the PDF attached - use Saved views and/or the Model Tree "decomposer" (file is greatly reduced in detail - only 1 out of 5 floors shown, no envelope stuff, stripped out of everything actually etc etc etc). Among a variety of things observe that there's transformations that are "selectively" applied whilst various components remain intact (in other words: invite existed "static" objects into the smart chaos) - this means that we need a far better control VS the series (of various type of data) that outline the solution of similar things.

3. What could/should do such a "visual" Tree Manager? Could he function within the existed "one Canvas for all things" environment? Do we need N "sub-canvas" (kinda the Views in any CAD app these days) to handle and visualize complex tree operations? Do we need control on a per data item basis? Do we need a re-mapper of a totally different kind? Do we need a Bake Manager? Do we need a Scenario (parameter combos stored etc) Manager?

Let's the debate begin

Best, Peter

Attachments:

THE NECESSITY FOR A TREE DECOMPOSER.gh, 36 KB
172_WIP_BASE-Default-045A.pdf, 4.2 MB

Replies to This Discussion

Permalink Reply by Danny Boyes on December 6, 2011 at 8:56am

Hi Peter,

In each Chaos Scenario what is the question/objective?

Permalink Reply by Danny Boyes on December 6, 2011 at 9:05am

You might find this useful.

Edit: The Merge Component is Optional

Permalink Reply by Danny Boyes on December 6, 2011 at 9:08am

Also have you seen the Data Viewer?

Permalink Reply by peter fotiadis on December 6, 2011 at 10:58am

Hi Danny

I know the Data Viewer ... but this is not what I gave in mind.

Consider cases where geometry definition is set (well...hopefully, he he) by means of nested series of data but you need a far better control on various combinations of possible/desirable "connections" in order to sample them for creating geometry - I mean creating things that belong to things who belong to things etc.

Probably I should "translate" this from Generative Components to GH in order to outline my line of thought.

Permalink Reply by peter fotiadis on December 10, 2011 at 1:04am

Well, I was a "bit" optimistic with regard the translation part of the equation. Main reason is that I mix already designed components (dimension driven or not according the case) with smart (???) stuff in a way that Rhino can't follow (say: editable in place nested assemblies of geometrical collections, solid operations, draw on face, selective un-instancing etc etc). Reason is that when the smart exploitation is over the structure of geometry (Refs and/or Cells) is ready for finishing the Project with the classic CAD way - the stupid one, that is.

Think for instance a cable tensioner combo (say: already designed) that has parts that can be modified/parametrized (like the length of a cable) and parts that are locked with regard transformations (like the size o a bolt and/or a membrane attachment collection of "layered" aluminum plates).

So the big thing in AEC smart stuff is to combine smart definitions (mostly transformations) on collection of industry sourced things (say: nested blocks in Rhino speech) that can being partially modified.

On the other hand the Solid engine in Microstation (Parasolids) is rather far superior to Rhino (but Rhino is better in NURBS) meaning that all these things other than being already properly "structured" (forget stupid Layers, think assemblies and components)...they are 100% solids as well.

I'll try to mastermind a more suitable test case - but it must be a bit complex other wise all these are meaningless: anyone can mentally manage some grid points in XY...but when points are N in M series (and working in one and only one Canvas...) that's another animal. Think also that in AEC business Projects are designed by teams (but the bad news is that a camel is a horse designed by a committed, he he).

All these point to a "state/phase" future GH capability that can manage complex "semi-baked" solutions - but more on that in some future thread.

Best, Peter

RSS