Data Trees - How and when is better to introduce them?

Hi all,

I would be great if you could share your experience on introducing and teaching the inherent logic of data trees in grasshopper to your students.

My interest lies primarily in the period during the courses at which data trees should be taught. Personally, I usually make a general introduction on the first times and then explaining them during the next lessons through examples. The thing is that this happens somewhere in the middle of my tutorial structure (always talking about novice level tutorials).

My question is whether something so important for the GH logic can be introduced efficiently during the starting steps of the learning process.

Has anyone tried this? And if yes how, care to share your techniques? Do you think this the appropriate practice?

Best,

Replies to This Discussion

Permalink Reply by GIL AKOS on October 4, 2012 at 9:30am

Marios,

Great question for the group. Ronnie and I feel that Data Trees need to be addressed as soon as possible - a solid understanding and precise use of Data Trees is absolutely necessary when trying to execute anything remotely complex or even at a more basic level for structuring how elements/numbers/etc are organized and related. In an academic course, we usually end the first 3 hour session with an introduction to Data Trees and then follow up with the second session unpacking Data Trees through exercises. We also tend to use visual presentations with our exercises to couple concept with application.

On a related note, we are actually conducting a Webinar on Data Trees tomorrow. We will be going over concepts and advanced uses as well as speak about our approach to teaching others about them. More info can be found here: http://modelab.nu/?p=7233

- Gil

Permalink Reply by Marios Tsiliakos on October 4, 2012 at 9:56am

Hi Gil,

I am quite aware of the work you have been doing at Mode Lab and you got my congrats for that. Really nice job! So you find it possible to introduce data trees through examples after 3h teaching? I usually attempt it after 8-9 hours. I have noticed a difficulty in comprehending data trees with numerical examples, where geometrical examples are better. Visual representation is essential either way,tree statistics is a big help from now on. Either way I am looking forward to see some of your examples some time..Thanks for you answer.

Permalink Reply by Massimiliano Trave on November 27, 2012 at 9:14am

Hi modelab i'm interested to buy some of your past webinar,that is possible in your site?you can explain me i can do that.

Thanks

Massimiliano

Permalink Reply by GIL AKOS on November 27, 2012 at 6:29pm

Hi Massimiliano,

Thank you for your interest. You can find details here (http://modelab.nu/?cat=1022) or email us at webinar@studiomode.nu. We look forward to hearing from you.

Permalink Reply by Michael Pryor on October 4, 2012 at 9:53am

I think immediately after UI an examples of how GH is like an infinite history state.

Permalink Reply by Hannes Löschke on November 5, 2012 at 6:52am

From a programmers point of view, data structures are essential to understand the whole concept of Grasshopper and its full capabilities. However most beginners have no idea they are actually coding by connecting those funny capsules with wires. As a programmer I'd say "theory first, then we move on to the really cool stuff." But most people prefer the trial/error method. They want to get started right away, see the first results, explore on that. Results encourage you to to move on, lots of theory will most likely just bore you.

I think most people need to get comfortable with the concept of components and data connection first. Then you can introduce them to lists. If some component creates tree structures, flatten them as long as you can. Only if there is a solid base knowledge of how you work the UI and find the components that fit best, you can move on to data structures.

Working with trees involves a lot of planning ahead. You need to know what data you got and where it should go. More often than not things will not work as planned. This is a really good way to frustrate beginners...

A Professor of mine once said: "GH is for when you are tired of doing the same thing in Rhino again and again." I'd like to add: "Trees are for when you are tired of copying the same bunch of components again and again."

Permalink Reply by Marios Tsiliakos on November 6, 2012 at 5:46am

I believe that the last sentence could easily justify the existence of data trees. Thank you for this quote Hannes, I am asking your permission to use it by referencing you of course.

Another thing I am doing lately is to encourage my students to make their own data paths within the data internalizing components from the first classes. This way I can achieve two things: 1st. they get familiar with the data tree syntax and 2nd.(which reminded me to post a question/wish to the forum), and more important they understand that one of the most basic attributes of gh is that you can record and re-flow your data in many ways. They might not be aware of how to use these paths, but when the 'cool stuff' needs some data management, it is way more easier for them to keep track and not to get frustrated with data trees.

Seems to be working until now.

Permalink Reply by Fred Becquelin on November 21, 2012 at 7:14am

Hi all,

Data trees is the very first lesson (after the UI) in my view. Gil's webinar video is the perfect start.

I think to learn GH you really need a motivating personal project. Doing all the exercises of the book is a bit boring...

My opinion is that a good GH jockey is not the guy who does his stuff with the fewer components or milliseconds, but the one who analyse his problem and highlights the logic backbone of the project, i.e. hierarchy / dependencies of parameters and the workflow essentially.

It's about pseudo coding really, and you can't do that at all if you don't know how to organize your data.

In that I have to disagree with Hannes; planning ahead is indeed the real thing.

My students have Rhino classes where they learn geometry and nurbs, construction classes where I teach them structure calculation, and architectural classes where they learn all the rest... In this perspective, GH is but a language and the first thing to learn is the basics of grammar.

Of course they are completely lost and exhausted at the end of the class. But at least they have the minimum knowledge they need to study by themselves examples on the forum, and start elaborating their own project.

To me, next step would be conditional statements, review of data types, and eventually an exhaustive list of ways to manage trees.

I partially agree that it may be a little boring. But you have to go through it anyway at some point, so why not get over with it straight away? Of course two hours of data treeing is unbearable for anyone, So you can spend some time in the forum galleries, see cool stuff and try to get how it's done. This will help them choosing their personal project.

All this is a bit theoretical, I don't have a lot of experience in teaching GH. Would love your advice.

Marios, I don't understand what you're talking about. Could you illustrate? It seems interesting.

Permalink Reply by Marios Tsiliakos on November 22, 2012 at 3:30pm

Hi Fred,

Thank you for your reply in this thread. The snapshot below illustrates what I was talking about previously. I encourage my students to experiment with data paths and even form their own inside the persistent data explorer.

By this process they seem to get a better understanding on how information flows within GH, even with the absence of a handy geometrical example. This way when the example comes at hand the have already acquired a certain understanding of what branch is , or how is a data path defined, and even better the syntax of data paths..

This technique seems to be working for me quite well for the last couple of months. I believe that it easier to understand and a lot easier for me to display and elaborate on.

Best,

Permalink Reply by Frans Magnusson on November 29, 2012 at 11:53am

A hands on example I like to use when introducing trees is the point matrix.

Analysing the output points with a tree item component together with a couple of panels and then flipping the matrix takes you quite far in explaining exactly what a list of lists is.

When to do it? Pretty soon - but not until you showed some geometry hooked up to sliders!

(thats why we all do this, isn't it?)

//Fr..

Permalink Reply by michael sprinzl on December 10, 2012 at 3:47am

DataTrees are quite easy to describle, but hell to handle with the tools supplied by Grasshopper. Lets try in google tree traversal.

The basic concept to get and put data into datatrees is this a recrusive function which calls it self.

This can be applied for all kinds of concepts like Lambda exression,Solvers,Dictonaries,XML parsing functional stuff etc...

TraverseTree(Node ParentNode)

{

foreach(Node SubNode in ParentNode)

{

TraverseTree(SubNode);

}

// Tail

// manipulate Node

}

We a talking about rooted trees, which means, what is has a entrypoint and a left and right side.

Permalink Reply by Marios Tsiliakos on December 10, 2012 at 3:56pm

Thank you Michael for this educational info..

One may argue on the "easy to describe" kind of thing.. However, I believe that is easy enough to describe datatrees to people acquainted with programming, but a living hell to non programmers.

Best,