[Edit: Siiiiiigh . . . this was a "bug" that got fixed in r2013]
Me: You can use a non-host element reporting parameter to drive a parameter in a nested family!
You: <ponder>
Me: Yes!
You: <ponder>
Me: But-but-but . . . You can use a non-host element reporting parameter to drive a parameter in a nested family!!!!!!!!
This is Cool! And maybe a little dangerous.
Regeneration in Revit is supposed to go like this:
Where changes propagate like this:
1. Host Elements
2. Reporting Parameter
3. Formula Driven Geometry
4. Other Regenerations
5. Final State
But with non-host element reporting parameters driving formulas you can get this:
1. Host Elements
2. Formula Driven Geometry
3. Reporting Parameter
4. Other Regenerations
5. Final State
See that little loop? That’s the regeneration sequence turning back on itself. This COULD be really bad, making something like this:
Where you never get to a final steady state and Revit explodes in a puff of logic and a red hot CPU.
I was kicking around a model with Ritchie Jackson, building a better deflection panel (it’s awesome) and I saw that he had hooked up a non-host element reporting parameter (that had no business driving anything) to drive a non-geometric calculation in the nested family. This was cool in itself, but the implications are pretty awesome (if you are into this sort of thing).
Dig:
Family1: A cube with a height parameter called “height” which is set as equal to 2*halfHeight, which is value 1’
Load Family1 into host. Add a dimension to the loaded cube height, make it a reporting parameter called hostHeight, which is currently 2’. You can follow along at this point with the looper_height.rfa file here.
Select the cube and set “halfHeight” to be driven by hostHeight.
Cube regenerates, then regenerates again. Cube is now 16’ tall! So it loops once to drive initial state (2’) back into the nested family (changes 1’ to 2’) which then makes the hosted family 4’, then does this 2 more times before stopping. If you nudge the extrusion it does a single loop each time it is nudged (32’, 64’, 128’). But if you hook up and un-hook up the parameter, it will do 3 loops each time: 2’, 16’, 128’, 1024’.
So it seems that Revit is actually stopping the loop from getting out of control, which is good. When I first hooked this example up, I wasn’t sure what was going to to happen. Logically, I figured it might just loop until it crashed.
Another example, this one is actually a goalseeker
Family1: a cube that has a height parameter called height, value 10’, set to be equal to (angle / 1°) * 1', and angle currently is 10°
Load Family1 into host. Host a line by points from the top edge of the cube to the bottom corner of the cube, put a reporting angle on this line like so:
Look at looper_angle.rfa file from here. Set Family1’s parameter “angle” equal to host family “angle”
First iteration:
2nd
5th
By the 9th iteration it finds a rough balance and makes very small movements around 59 degrees and 59’:
Goooooooooooooooooooooal-seeker!
More to come on this.
Me: You can use a non-host element reporting parameter to drive a parameter in a nested family!
You: <ponder>
Me: Yes!
You: <ponder>
Me: But-but-but . . . You can use a non-host element reporting parameter to drive a parameter in a nested family!!!!!!!!
This is Cool! And maybe a little dangerous.
Regeneration in Revit is supposed to go like this:
Where changes propagate like this:
1. Host Elements
2. Reporting Parameter
3. Formula Driven Geometry
4. Other Regenerations
5. Final State
But with non-host element reporting parameters driving formulas you can get this:
1. Host Elements
2. Formula Driven Geometry
3. Reporting Parameter
4. Other Regenerations
5. Final State
See that little loop? That’s the regeneration sequence turning back on itself. This COULD be really bad, making something like this:
Where you never get to a final steady state and Revit explodes in a puff of logic and a red hot CPU.
I was kicking around a model with Ritchie Jackson, building a better deflection panel (it’s awesome) and I saw that he had hooked up a non-host element reporting parameter (that had no business driving anything) to drive a non-geometric calculation in the nested family. This was cool in itself, but the implications are pretty awesome (if you are into this sort of thing).
Dig:
Family1: A cube with a height parameter called “height” which is set as equal to 2*halfHeight, which is value 1’
Load Family1 into host. Add a dimension to the loaded cube height, make it a reporting parameter called hostHeight, which is currently 2’. You can follow along at this point with the looper_height.rfa file here.
Select the cube and set “halfHeight” to be driven by hostHeight.
Cube regenerates, then regenerates again. Cube is now 16’ tall! So it loops once to drive initial state (2’) back into the nested family (changes 1’ to 2’) which then makes the hosted family 4’, then does this 2 more times before stopping. If you nudge the extrusion it does a single loop each time it is nudged (32’, 64’, 128’). But if you hook up and un-hook up the parameter, it will do 3 loops each time: 2’, 16’, 128’, 1024’.
So it seems that Revit is actually stopping the loop from getting out of control, which is good. When I first hooked this example up, I wasn’t sure what was going to to happen. Logically, I figured it might just loop until it crashed.
Another example, this one is actually a goalseeker
Family1: a cube that has a height parameter called height, value 10’, set to be equal to (angle / 1°) * 1', and angle currently is 10°
Load Family1 into host. Host a line by points from the top edge of the cube to the bottom corner of the cube, put a reporting angle on this line like so:
Look at looper_angle.rfa file from here. Set Family1’s parameter “angle” equal to host family “angle”
First iteration:
2nd
5th
By the 9th iteration it finds a rough balance and makes very small movements around 59 degrees and 59’:
Goooooooooooooooooooooal-seeker!
More to come on this.
But.... I thought you told me I couldn't drive parameters with non-hosted reporting parameters... BTW, my head now hurts a little... :-)
ReplyDeleteRight! You can't drive other parameters inside the file, but it looks like nested params are sneaking in.
ReplyDeleteMy head hurts... A LOT. But in a good way. Gotta get this in the right hands...
ReplyDeleteA very interesting discovery. But I have a feeling that this is a design bug of Revit 2012. I tried to do this in Revit 2013 and it does not allow me to associate parent family's reporting parameter to the nested family's parameter. However, when I repeat the same experiment in Revit 2012 it works fine.
ReplyDelete