Example Files, etc

Replies to This Discussion

Permalink Reply by David Mans on October 26, 2017 at 12:25pm

Marc,

I'll put together some basic sample files shortly and post them.

My hesitation has been that since many of the components are being reworked, alot of IO errors occur when their inputs get re shuffled.

But, I'll come up with some core workflow samples as its a sprawling toolkit right now with no descriptions on components.

For the Red Component errors, at this time, geometry needs to go through a "Shapes" component. Eventually, generic geometry inputs will be filtered as well, so they can be used as direct inputs. But right now they need still need the step of going through the shape.

Also a quick note, the SVG node was broken at AEC. This is on the short list for updating for the next release.

Permalink Reply by Marc Syp on October 26, 2017 at 7:17pm

Great, thanks for doing that.

I understand regarding updates and input errors -- I know I try to keep my plugins away from end users until I'm ready to start deprecating components properly, to avoid the nuclear winter that results from serialization errors.

I did try passing the geometry through shape components but was still getting errors -- but I was probably doing something wrong still... will wait for those sample files to see if there is anything else nefarious going on with dependencies, etc.

Also looking forward to that fixed SVG component!

Cheers,

Marc

Permalink Reply by David Mans on November 5, 2017 at 12:56am

Marc,

Some preliminary sample files are uploaded the Food4Rhino page. 

These will require the latest version as well which is up for download.

http://www.food4rhino.com/app/aviary

Still alot of development to be done, but hopefully this begins to open the door to some applications.

Note: SVG is still not updated and not all drawing objects, such as text, are fully active /  cross checked. This will be the primary focus of the next update.

Permalink Reply by Marc Syp on November 6, 2017 at 8:52am

Hi David -

Thanks for doing this... Unfortunately, at ACADIA I tried to do a demo of my existing project (the one you saw at AECTech) and discovered that Aviary does in fact break HumanUI when its dependencies are loaded.  Unfortunately that's a dealbreaker for me if we can't somehow reconcile the shared dependencies.  I had to uninstall Aviary to get my demo up and running.  We should discuss, because I think there are great opportunities for both to coexist.

In the meantime, is there/will there be a way to deploy Aviary "a la carte" -- that is, still get some SVG functionality without installing the WPF-dependent tools?  It's very difficult to understand the severability of the various pieces, and perhaps it's not possible.  But I'd love to explore the possibility if it exists.

Cheers,

Marc

Permalink Reply by David Mans on November 6, 2017 at 12:49pm

Hi Marc,

I run both Human UI and Aviary together, the conflict in dependencies comes from:

• XCeed.Wpf.Toolkit.dll
• Mahapps Metro

As I run a slightly older version of both.

The way I solve this is to move both into Sub folders 

• ...\AppData\Roaming\Grasshopper\Libraries\HumanUI
• ...\AppData\Roaming\Grasshopper\Libraries\Aviary

This seems to solve the problems on all systems I've run them on.

I just had to make sure that none of the dependencies were in the base \Libraries\ folder.

To the question of severability, the different facets can be run a la carte. The different categories, Vector (Hoopoe), Raster (Macaw), Charting & Data (Pollen), 3d Modeling (Flock), and WPF Dashboard (Parrot) are all independent with a common dependency on (Wind). These keep their respective dependencies partitioned, however these is currently some crossover as part of the development process which will be separated again upon the first official release.

Permalink Reply by Marc Syp on November 9, 2017 at 6:59am

Hmmm... interesting.  I had already separated the plugins into their own folders. However, my understanding is that Grasshopper won't load multiple instances of the same dependency, rather, it just loads the first instance it encounters and ignores the rest -- could be wrong about that, but this has tended to play out in the classic Newtonsoft.Json.Dll conflict over the years.

That said, it's possible that your system's particular load sequence happens to load HumanUI's newer dependencies, thereby avoiding problems?  I'm going to run a test where I install all of Aviary's components except for the above-mentioned dependencies, and see whether the WPF components in Aviary can depend on HumanUI's files...

Marc

Permalink Reply by Marc Syp on November 9, 2017 at 7:43am

OK -- results of a few tests:

1) Tried installing only Aviary's components, left out the WPF dependencies -- I got one error during GH load related to WPF.ToolKit (some color method not existing), which I presume is from Aviary accessing a method that no longer exists in the the HumanUI dependency.  Loading 11-Basic-Vector-Drawings.gh crashed Rhino/GH

2) Installed all of Aviary's dependencies, in their own Aviary folder, with HumanUI folder encapsulating its dependencies as well (as before).  GH loads fine, and Aviary sample files work (awesome!).  HOWEVER -- HumanUI is completely broken... Value listeners not working, SimpleGrid not working, just generally broken.  Clearly the Aviary dependencies are loaded first (I think order is alphabetical in the root folder, followed by alphabetical subfolders) and they break HumanUI.  

I know it's not a great long-term solution, but is it possible for you to update Aviary to work with the same dependency versions of HUI for the first release?  Is there a big discrepancy in the methods, or are there legacy methods that you need for some reason?

Finally -- when I had Aviary working, it was really fun to play with... but I couldn't figure out how to export an SVG drawing... also the terminology of the inputs is confusing. Why would I pipe a bitmap into a vector image format?  

Anyway, happy to hear your thoughts.  I really really would love to get some kind of Aviary workflow up and running in parallel with HumanUI...

Marc

Permalink Reply by David Mans on November 9, 2017 at 9:31am

Marc, Thanks for spending all the time to work through this!

I was not aware of the issue of breaking Human UI's components, so that is something I will definitely address. 

Matching the version of the libraries that are in conflict with HUI should be doable. The problem before was the color method issue and also a version conflict with the material design library. However, I believe the latter is resolved now. I'll make that a priority, and post an new version as soon as I am able to resolve it.

Regarding the SVG issues, this all worked great about a year ago has been broken since I detached the drawing workflow from Parrot into Hoopoe and changed the whole structure of the underlying Wind geometry library. Its lived in the backlog to be repaired ever since. The write SVG component is currently inactive, and I'm working on updating that now, as well as rounding out all the issues with the current vector drawing workflow. 

However the SVG the process will work just like the WPF drawing, just instead of going into the Compose Drawing component, it goes into the Compose SVG. The output then goes into the "Write SVG" component (which is just mislabeled at the moment). I'm slowly adding proper descriptions and checking labels as I go.

Not sure what the timeline on getting these updates up will be, but it is top of my priority list and under development right now.

Permalink Reply by Marc Syp on November 9, 2017 at 9:49am

David --

This is super great to hear.  Really looking forward to these developments, and I will be your #1 champion as these things come to fruition! 

Cheers,

Marc

Permalink Reply by David Mans on December 4, 2017 at 2:17am

Marc,

Posted a WIP update to Aviary which appears to fix all the conflicts with the latest build of HUI. I believe all relevant shared dependencies are brought up to the same version now.

This is also includes several other incremental updates and the initial update to the SVG output component. The SVG pipeline will currently work with Lines, Circles, Ellipses, Polylines, & Splines. But does not yet deal with compound paths (curve booleaning) as of this release, though this should be coming very soon.

Basic graphic functionality for Stroke[Color, Weight, Pattern, Opacity] and Fill[Color, Opacity] are active, many more facets of this are under development. As I wasn't satisfied with any existing libraries for .net to SVG, I've just been writing one from the ground up in Hoopoe. So alot more to come on that front. 

In the meantime, I've linked to a download of a SVG Sample which shows the basic workflow:

https://www.dropbox.com/s/pm60ncm3sesbcu3/Aviary-SVG_WIP-Test.gh?dl=0

Permalink Reply by Marc Syp on December 4, 2017 at 12:15pm

This is great David, thanks for the update.  I will definitely check this out soon. 

Incidentally, I have been writing a new plugin called "Pollen", which is designed entirely around adding support and fine-grained control over the Excel 2017 COM objects, to be used with Bumblebee.  :)  I was unable to get Bumblebee working with the latest Excel, and I wanted to add more fine-grained control over file creation, application processes (killing background processes primarily), etc. Now that it's mostly working, I'm really enjoying all of the flexibility you've built in to Bumblebee.   It's working great.

Anyway, I'll share that when it's ready, still more testing to do...

Cheers,

Marc

Permalink Reply by David Mans on December 4, 2017 at 12:53pm

Marc,

That's great to hear. 

I would also recommend checking out Konrad Sobon's work on Bumblebee for Dynamo. He reworks the approach to data management with an approach that made working with it much clearer.

http://archi-lab.net/bumblebee-dynamo-and-excel-interop/

Thanks,

David