Goal amount for this year: 2500 USD, Received: 1627 USD (65%)

# Thread: What Are People Doing For Trees?

1. ## What Are People Doing For Trees?

The ultimate goal would be a rather simple parametric 3D "lollipop" tree, with instance based parameters for height and canopy width, that then has detailed 2D views in plan and elevation:

We currently just use 2D detail components for trees but it means there is no connection between the views - if you add/move a tree in plan you have to make sure the change is reflected in all elevations. One idea is to just use skinny "trunks" for the trees, so that the detail components can then be aligned properly between views, but there is no way (that I'm aware) to layer the detail components behind buildings. Furthermore, there are scaling issues with the 2D detail components. And if we're going to use a trunk I figure we might as well use a lollipop to give some sort of context for any 3D views.

Making the lollipop is easy enough, as is creating a 2D representation of a tree in plan and elevation. The issue is that the 2D views are filled regions that won't scale. The other issue is that as soon as there is an elevation that isn't square on to the tree, then the lollipop becomes visible. (We can rotate the tree to that elevation but then it likely throws it out in another view - it's not always the case that all elevations will be perfectly square with each other.)

We're avoiding the elevation issue for now and just worrying about plan, and created separate filled regions for different sizes. This is nested into the lollipop and the varying sizes turned off/on with visibility parameters. The issue with this is that at 1mØ all sizes greater than 1m turn off, however, they still exist in the family and so doing a crossing box far away from the tree means that it is still selectable. Given the sizes currently go up to 25m it means that there is effectively an invisible box 25mx25m around every tree instance. There is also a rather tedious amount of lag when placing and adjusting the trees (I'm guessing due to the 1000s of detail lines?)

Is there a way to somehow scale the filled region? We tried creating a "grid" of sorts with reference lines, and we can get this grid to grow and shrink as we desire. We were hoping that drawing lines to the corners of the grid would mean they would grow and shrink with the grid, but this is incredibly hit and miss to say the least.

And when we consider the elevation issue:
A lot of the time in elevation we can then see the lollipop and replace it with a detail component, but this is a nightmare when you want to layer the detail components behind trees. Another idea has been to create a 3D extrusion in elevation that can be rotated to face the elevation square on - this way it can be layered behind things. However, there is again the issue of it looking fine in one view and not square in another. Adding multiple extrusions so that they can each face an elevation is an idea, but it now means the trees will have multiple 3D planes showing in each elevation, all at different angles, and so now there will be (undesirable) vertical lines and shadows being cast on them. And again we run into the issue of not really being able to scale the tree.

What are other people doing?

2. Other people use google and scale their trees.
https://www.google.com/search?q=revi...20scale%20tree

3. Andy Milburn from Shades of Grey, has an awesome post about how he does them
There is the Scale-able Nested Family trick etc
Shades of Grey: Search results for trees

4. Having gone through all of this, for a client, I can say that creating fully parametric families that report data in schedules for all trees, is possible but it is extremely difficult. It involves connecting five families, for every tree, like this:

1) detail item family (plan view)
2) planting
(plus... shared parameters...)
3) planting
4) generic model
5) planting, plus render appearance

Then load into project.

Another alternative, instead of doing all this work, is to buy a license of CS Artisan.

5. Originally Posted by Alfredo Medina
Another alternative, instead of doing all this work, is to buy a license of CS Artisan.
We use CS ArtisanRV.

I just gave a presentation at BILT ANZ 2019 in Melbourne a fortnight ago on landscape architecture and Revit and how Artisan plugs the gap in Revit to give a comprehensive workflow in Revit for landscape architecture firms.

6. Originally Posted by kamranmirza
We use CS ArtisanRV.

I just gave a presentation at BILT ANZ 2019 in Melbourne a fortnight ago on landscape architecture and Revit and how Artisan plugs the gap in Revit to give a comprehensive workflow in Revit for landscape architecture firms.
I was really looking forward to this class, and i cant wait to get the handout. Ive been eyeing the ArtisanRV suite for a little while, thinking that- if its all done well, and not junk on the inside- it would pay for itself in short order. Like, its everything Site Builder should have been, LOL.

7. Existing trees, Concept trees, Detailed trees, Root balls, Tree pits, Aging, Visualising - plan, elevation, 3D, RPC, Full schedules, Substitutions... it all needs to be modelled in a robust and easy to use way. This is what CS ArtisanRV is developed to deliver. Like the reference to everything Site Builder should have been, Aaron! Kamran's BILT ANZ 2019 presentation provided a really comprehensive message of the workflow in Revit for landscape architecture. There is a similar presentation at AU London 2019.

8. The issue with a lot of the google results (I'll admit my previous investigation was half-hearted at best) is they're quite old articles, often recommending using DWGs, and I haven't found anything that allows both height and width to be instance-based parameters. And the elevation issues - a 2D detail item will always need to be square to view, a 2.5D detail item will cast shadows on itself - seem to remain.

Originally Posted by Alfredo Medina
Having gone through all of this, for a client, I can say that creating fully parametric families that report data in schedules for all trees, is possible but it is extremely difficult. It involves connecting five families, for every tree, like this:

1) detail item family (plan view)
2) planting
(plus... shared parameters...)
3) planting
4) generic model
5) planting, plus render appearance
does that get you both height and width to be instance based? i found a similar workflow proposed here:
https://landarchbim.com/2015/07/29/c...cs-simplified/
although that one seems to only be detail component>planting family>planting family.
The issue I encounter with the above link is that height has to be a type parameter for the scaling to work, and all my workarounds have failed. It seems the in-built "Height" (type) parameter that comes with planting families is unavoidable - even if I don't use it and don't use it in any equations, it still ends up manipulating the scaling in a project environment. It could be that your additional steps of (4) and (5) solve this issue? If this is true, and you can get both height and width to be instance based then could you possibly expand a little on the workflow?

Will definitely keep my eye on CS Artisan, thanks for the recommendations. Anyway to see the handout? Someone from our firm was at the Melbourne conference, although evidently they didn't attend that presentation

9. OK pretty sure I've got height and width instance based and independent of each other, with simple geometry and plan graphics behaving correctly (2000mm seemed to be a magic number when doing the scale calc? EDIT: 2000mm was original size of detail component) but I've realised that having any sort of graphical representation of a tree in elevation that can flex this way is maybe impossible... If I have 2x10m tall tree, one is skinny and one is fat, it's not going to be possible to stretch a 2D component along one axis only to suit, is it?

10. Thanks for the help and advice everyone, Alfredo I still don't understand why the need for embedding into a generic model, but it helped me out when things weren't working

As far as I got today:

One family and one type for all the trees (which is what I was after).

-Tree width is parametric (instance) and plan symbol will scale appropriately, with graphics options for wire frame, solid white, and greens. Given it's a 3D family any graphic choices will apply to all views, so I'm guessing we'll embed all the trees into a design option and have options for wire frame, white and green. In the future I will create a few variations of plan symbols.

-Tree height is parametric (instance) and elevation symbol will scale appropriately, relating to the height. The elevation graphic I've used is just a place holder for now, will create a few variations (fat one, skinny one, top heavy one, etc.) and it will then be up to the user to select which ever graphic gets them closest to the desired tree width.

-In 3D views we will generally just opt for the basic lollipop tree (that obviously corresponds to the width and height parameters) but if users wish for a realistic mode then the RPC models will show up and are again controlled per instance from a "Species" drop down menu.

-I made 3D planes of the elevation graphics that likely won't be used so much in 3D but could come in handy as a "better-than-nothing" option for non-orthogonal elevations. So for the non-orthogonal elevation views it's obviously just going to be the 3D view in elevation.

I don't know why the 2D components seem to scale fine (and by fine I mean with some effort) with the following working flow:
Detail Component.rfa>Planting.rfa>PlantingFinal.rfa

But when it came to the 3D planes they had to follow the steps Alfredo mentioned earlier:
Planting.rfa>Planting.rfa>Generic Model.rfa>PlantingFinal.rfa

Anything other than that and the 3D elements didn't seem to want to scale. Also, despite being drawn at the same size in their child families, some of the elements needed different scale formulas. The 2D stuff did weird inverted scaling whereas the 3D elements scaled more logically.

In any case, still happy to hear any other input or work flows, otherwise I will probably add in some more plan and elevation/plane symbols and consider the issue close to well enough resolved for now.

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•