Hope all is well! Been enjoying your tweets lately
Just wondering, would it be possible to update the bouncy solver so that the outputs are tree based as per the main solver? It’s only from an educational perspective, it can be more intuitive to use the bouncy solver in the first instance when showing how systems behave and then shift to the main solver for speed. However, unless I’m being silly (highly likely), the outputs are not grouped in the same way:
It might have been done for a good reason, in that case no problem!
Oh I’ve seen this before - usually Unflatten Tree does the trick (ie. the list is in the right order, Kangaroo just outputs it as a flat list).
(by the way nice to talk virtually! We met ages ago when you came to 3DReid to see Charlie Whitaker. You told us about your Kohonen map plugin, which at the time went completely over my head)
Hi @jopsa2 , yes I remember! It probably was a while ago now. I was trying to get Embryo to work, it never quite worked as well as I’d hoped in the end but the process in getting there was invaluable. I remember Charlie helping out quite a bit. Are you still at 3dReid? The Kohonen map is still a favourite, goes back to 2007 when an old friend Christian Derix was doing the first real applications of ML in architecture at UEL, way before anyone else was. I was hooked from that point on.
Anyway, indeed, I can just use unflatten tree with the guide data structure from an earlier entwine. I must be getting old now not to see these things, thanks for the help Hope to see you again soon.
Yep that’s usually what I do, and keep any geometry I want on the other side on a branch I can retrieve later.
The 3DR chat must have been in 2015-ish? So a while ago! I’m not there any more though.
As for the Kohonen map, it must have stayed in the back of my head for ages, because I did end up using it some years later! For my own research on room layouts: http://www.johnporral.com/entries/bedroomCloud.html
It’s a reasonable question about the bouncy solver. I originally meant to make it so the data tree output works the same as the standard solver. The Entwine/Unflatten method does the trick though, and because this workaround is easy enough I keep forgetting to update it, but still - I know it would be a nice little convenience to have that unflatten happen in the component itself so one less component is required. I’ll try and get this updated.
While we’re on the topic though, I’d be interested to hear your thoughts on something related.
Another option I’ve considered as a bigger change (possibly for Kangaroo in GH2) is to add a ‘Geometry’ input to the solvers, more like how it was in Kangaroo1, so that the Show component wouldn’t be needed. This could even maybe use the ZUI to allow adding extra inputs as needed, with corresponding outputs appearing automatically.
This leaves the question of what should then happen with Goals like Length that already output display geometry though. One option could be to still output those lines in GoalOutputs, while another way would be to get rid of the line output from the Length goal and have all geometry go through the Geometry inputs, keeping GoalOutputs for numerical and other non-geometric values.
Thanks Daniel, yep it’s just when I’m swapping out the two components during teaching. I suppose in theory I should be using entwine always, so it’s just one of those things. Some of the students approach K2 before really understanding trees to be honest, which is why this situation occurred.
With regards the geometry, sounds like a good idea (at least to me!) and a little more intuitive than using the show component - I guess that’s why it’s been in your thoughts. Of course so long as it doesn’t introduce any more spaghetti upstream, but I can’t see that it would as you could just entwine/merge geometry as is currently the case to keep the definition clean.
Personally, (and disclaimer: I don’t know the full repercussions here!) it feels like it should probably be ‘all in’, in the sense that if you still had components that previewed geometry independently of the geometry inputs it could get confusing. I’m thinking here in terms of Karamba, where there is a clear workflow from geometry → physical properties → solution/analysis. The adding of physical properties (or goals) doesn’t preview geometry up or downstream, this enables latter components to handle the display, such as previewing deflections, forces, etc. which may be something you’d like to do with K3 in the future, at least with the GoalOutput data? Default would of course just to preview only the geometry that finds its way to GeometryOut. The question as to whether points are displayed by default, probably 50/50 on that one.
Zoomable inputs also sounds nice. The danger is of course the component grows really large for some users, so perhaps there would be a cap in terms of numbers of additional inputs? (if that’s even possible). Overall though, definitely a good move away from the show component at least in my humble opinion!! Thanks for reaching out. Hope you stay well, hopefully there should be a chance to meet again soon.
I’ve really appreciated how the Show goal and GoalsObjects DataTree input/output of the solvers helps structure quite minimal/similar (in terms of graph topology) Kangaroo-based pipelines, and make it simple to switch between solvers by rewiring just two wires. Here’s a recent example I had open in a slideshow, where I was demonstrating such “separation of concerns” :
So I’d personally love if this dataflow design would remain supported. And that the other solvers would automagically unflatten the goal outputs like the standard solver
Edit: Tried uploading a larger image, but Discourse appears to severely downsample now.
That does look nice and clean, agreed! Ah the trouble with being a developer eh.
I guess ideally one solver component that could switch the way it works (fast, bouncy, etc.) would mean no switching of inputs at all, which would be preferable.
Again, personal opinion here but it’s always been a little odd that the ‘show’ is essentially something you feed into GoalObjects because it’s not really a ‘goal’ as such - however it does indeed keep wires tidier in many cases (hence my non-spaghetti comment) and gives a single output as you mention Anders. Maybe I’m coming round to your perspective on this!
I do think the Karamba workflow does work quite well though in terms of assembling the model in a structured fashion one stage before analysis and viewing the results.
