Worm (WIP) overview

Comment

Comment by Kristoffer Negendahl on June 16, 2014 at 2:13am

Hey Ángel. I've had troubles with this issue myself. When coupling GH to various simulation tools, tools that require vast amounts of detailed inputs, the interface in GH seem overly complicated for the user. Especially if every input can be variables. One approach is to automate as much input as possible thus reducing the necessary user control, however this may also reduce the functionality of the program/script you are using. The approach I've settled with now is systematic use of dictionaries (i use python) combined with the "zoomable interface option in GH". With dict you can input (multiple) lists with attached keys that acts as a custom name for that particular data. The dict can then be sent around to your various other modules where you can operate on the data with specific keys attached e.g. myDictWalls['WallArea'] gives me all data with the key 'WallArea'. The dict may contain any mix of data you like, of course you have to handle the data yourself. This reduces the amount of inputs between modules and allows you various "versions" of modules, which can be be more or less complicated for the user.

The problem with dictionaries is the data-conversion procedures, which can seem quite redundant. Taking large arrays of heavily branched lists (e.g. of points) may slow the script down allot when converting to dict. But until now this has not been my main concern.

By the way @ Dr.No. How is it going with Worm? It is such a cool piece of work, I really like to see more.

Best Regards

Kristoffer 

   

Comment by Ángel Linares on June 13, 2014 at 12:57pm

Reviewing the video, it brings back to my mind some concerns about the GH interface: there is no a real good way to deal with components that need huge number of data inputs (that are very common when you deal with technical tasks). What could be the best approach here? Is there any forum topic about general guidelines to design plugins and keep a consistent and as good as possible user experience? Just bringing my thoughts out...

Comment by Michal Dengusiak on April 8, 2014 at 12:49pm

Hi This is amazing...I just come across it...WOOW...congratulation I need to learn more about this,

Comment by kytap on October 16, 2013 at 9:13am

nice work.

Comment by txingyu on October 14, 2013 at 9:17am

The impressive stuff of the year! Although Revit MEP could do better serious job, this experiment might enlighten non-MEP knowledge user then provoke them to think differently. Because the current convention design really is stuck and needs something fresh. Great attempt.

Comment by Doctor No on October 14, 2013 at 5:59am

@Reza, @Angel, @Kristoffer, thanks! Hope these experiments about transferencies in datatrees come in handy in some way, I will try to show all the inner processes ASAP to clarify this, if someone wants to reproduce similar workarounds

@Djordje, glad you like it!, it´s nice when it comes from such an active and generous gh forum member like you; Worm3basics works this way: The first step is sorting the data tree of the elements of the project in this tree structure {X;A;B;C;D;E} (X=Urban Duct / A=Building / B=B.ServiceRoom / C=column / D=Unit(dwelling) / E=Sub-unit(wet area)/ Items=cons.points) You can let the first project components manage it for you, or you can input a data tree of points previously generated manually into the second step, the worm components (water worm, earth worm,etc) By doing this, you can manage large multi-building (urban) data and you also can select any route to each element choosing its branch, or you can select any element type (for instance, all the columns are stored in {x;x;x;x}) applying a mask to the whole tree. I understand MEP topologies as part of the project design, so you can specify the connections 1-just inputting the branch paths you want to be connected, or 2- letting the automatic sorting components make this for you by a closest-point logic (in the video, the component named "project data tree"), or 3-inputting a tree ordered by a shortest path logic (i.e. Dijkstra s.p.,spyderweb add-on, etc), that´s your designing decision. There are parts of the final tree drawing always selected with shortest path sorting, as the connections of the point-of-consumption inside every wet area, just to simplify.

@Luis, thanks Luis! Thank you very much for your kind words. I absolutely agree with you regarding interoperability with other software standars, but at this point I´m using worm as a support tool for sketching b.services for academic research (teaching and thesis) purposes; in any case, detail drawings will come as we have progressed enough with all types of b.services. And yep, that is the idea, is nice to use GH in all possible ways

Comment by Kristoffer Negendahl on October 12, 2013 at 5:02am

Very impressive.

Comment by Luis Fraguada on October 12, 2013 at 3:37am

Some serious stuff!  How about detail drawings of all of this for documentation?  Super impressed!  Well done.  I guess my only concern would be compatibility with existing standards of MEP documentation, so some interop with other software could be really interesting to extend this.  In any case, it is a ton of work you've put into this and I am really excited to see GH used in this manner.

Comment by Ángel Linares on October 11, 2013 at 5:06am

Amazing!!! :)

Comment by djordje on October 9, 2013 at 1:19pm

Saw your other video (Warm3 basics) too.
Wonderful work!
The definition calculates the shortest path for water pipe line from consumers points to water source connection point?

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