This is the long promised follow up and download post.
I have taken a standard ootb Revit planting family (RPC deciduous) and modified it to achieve several ends.
The symbol family, aka "deciduous base", contains a vertical model line, (invisible) controlled by a "height" parameter; plus a bunch of symbolic lines to represent the tree in plan views.
Normally this is contained within the nested planting family. (i.e. the nested family has 2 things inside it, the deciduous base, and a strange object called "render appearance" which is not a family.)
I have separated these 2 components into separate planting families, each nested into the host planting family. There is only one "render appearance" family, which has the capacity to represent many trees. I have opted for 5 "base symbols" which can be selected by means of a type parameter.
Rotation is achieved very simply by a labelled angular dimension. This only affects the "render appearance" It would be possible to also rotate the plan symbol by random amounts, but it didn't seem to me that this was necessary. Plans are by the nature rather abstract and formalised. It is in the 3d views that we really want to inject some random variation to better simulate natural plants.
The size of the "base symbol" is controlled by a width factor. This varies the height of the invisible line (the "stick") by way of a formula. What matters is the relationship between symbol size and stick size. So a fat tree needs a shorter stick. Hence the formula divides Height by Width Factor to derive Stick Height. By a process of trial and error, you can find an appropriate Width Factor for each species of tree contained within the render appearance. Once set this is good for all time.
The way the height scaling works is a bit tricky to explain. All planting families have a type parameter called "Height" baked into them. In the nested family this controls the height of the stick. For each species of tree, the stick height is adjusted to match the height of the Render Appearance. Planting families have a special behaviour. Double nested families will automatically scale so that the tallest piece of geometry in the nested family scales to match the Height parameter in the Host family. You don't have to link any parameters, it just works that way.
BUT the Render Appearance is not a normal family, it doesn't count as geometry. So if the Render Appearance is 10% taller than the stick, it will eventually be 10% taller than the stated height in the Host family when this is placed in a project.
Even if the stick is removed the Render Appearance will act "as if" there was a stick of the stated height. Don't worry it also confuses me. In the end I solved this by trial and error with only a hazy idea of what was going on behind the scenes.
Download the family from here
TREE FAMILY (many types)
Or a project file with a fuller explanation from here
TREES COLLECTION
I have taken a standard ootb Revit planting family (RPC deciduous) and modified it to achieve several ends.
- plan symbol to match the width of the 3d object
- an instance parameter to enable random variation of rotation angle
- an instance parameter to enable (small) random variations of height
The symbol family, aka "deciduous base", contains a vertical model line, (invisible) controlled by a "height" parameter; plus a bunch of symbolic lines to represent the tree in plan views.
Normally this is contained within the nested planting family. (i.e. the nested family has 2 things inside it, the deciduous base, and a strange object called "render appearance" which is not a family.)
I have separated these 2 components into separate planting families, each nested into the host planting family. There is only one "render appearance" family, which has the capacity to represent many trees. I have opted for 5 "base symbols" which can be selected by means of a type parameter.
Rotation is achieved very simply by a labelled angular dimension. This only affects the "render appearance" It would be possible to also rotate the plan symbol by random amounts, but it didn't seem to me that this was necessary. Plans are by the nature rather abstract and formalised. It is in the 3d views that we really want to inject some random variation to better simulate natural plants.
The size of the "base symbol" is controlled by a width factor. This varies the height of the invisible line (the "stick") by way of a formula. What matters is the relationship between symbol size and stick size. So a fat tree needs a shorter stick. Hence the formula divides Height by Width Factor to derive Stick Height. By a process of trial and error, you can find an appropriate Width Factor for each species of tree contained within the render appearance. Once set this is good for all time.
The way the height scaling works is a bit tricky to explain. All planting families have a type parameter called "Height" baked into them. In the nested family this controls the height of the stick. For each species of tree, the stick height is adjusted to match the height of the Render Appearance. Planting families have a special behaviour. Double nested families will automatically scale so that the tallest piece of geometry in the nested family scales to match the Height parameter in the Host family. You don't have to link any parameters, it just works that way.
BUT the Render Appearance is not a normal family, it doesn't count as geometry. So if the Render Appearance is 10% taller than the stick, it will eventually be 10% taller than the stated height in the Host family when this is placed in a project.
Even if the stick is removed the Render Appearance will act "as if" there was a stick of the stated height. Don't worry it also confuses me. In the end I solved this by trial and error with only a hazy idea of what was going on behind the scenes.
Download the family from here
TREE FAMILY (many types)
Or a project file with a fuller explanation from here
TREES COLLECTION
Wow Andy, you've dug pretty deep into these families.
ReplyDeleteGreat post.
FYI, Your download links don't work.
Thanks Justin, seems to be working OK for me now. Will get someone else to test it in the morning. Too tired now ... need sleep
DeleteThe Collection works, but the Family doesn't.
DeleteI think I might give up on Google drive & stick with Autodesk 360
ReplyDeleteI managed to download the family (it was a 2 step process), but I don't have v2014 installed here so i can't test it. However, I am mightily impressed to read what you've achieved - I wish I'd known all this stuff a few years back (i have figured out some of it since then, but not all that you have). thanks so much. I thought you would be too exhausted from the pumpkin comp to come up with anything as good as this so soon!!
ReplyDeleteThanks Tim Actually most of the work was done some time ago, I just had to clean up the files and remember what I did ... then record it a bit more systematically. I'm hoping maybe someone will volunteer to do one of the other RPC families in the same way :-)
ReplyDeleteThanks a lot Andy! Amazing work...
ReplyDeleteIn the "Collection" the "width factor" it's the same for all the types, but its easy to change with the values that your already give us in the two sheets in the file.
Thanks again Andy!
Good work Andy, I have my own scalable planting families combined with dp stuff's randomizer addin (free on app exchange) for height and rotation automation.
ReplyDeleteHowever, I couldn't get the rotation to randomise throughout a full 0°min - 359°max angle value without my trees moving away from their origins. I would constantly get the 'constraints broken' warning. No matter what I did I couldn't get the 'stick' to lock/align to the ref. planes.
I have only downloaded and looked at your single tree family above but your method of nesting the plan detail symbol and the render appearance separately into the host family now allows me to align/lock the 'stick' to the ref. planes (tab select in plan view). I see your family doesn't have this done so you may like to do the same to keep it centered.
Thanks Elton, it's interesting that others have hit on the same idea. Surely as a community we can do more to share ideas and effort. I was also using the DP randomized (an excellent example of community sharing) Didn't bother me too much to randomize between 10 / 350 ... still gives the random effect. But of course you have to remember, which is probably your point.
ReplyDeleteIs there any chance to open it in Revit 2012 :c ?
ReplyDeleteGreat work on these families, Andy, and thanks a lot for sharing. I really enjoyed your presentation at BILT in Denmark :-)
ReplyDeleteThanks Martin, always good to get some positive feedback.
DeleteThank you so much for sharing this!
ReplyDeletethank for the wonderful post , lots of information gained , visit us Revit Modeling in uk
ReplyDelete