Tuesday, February 26, 2013

Voids Voids Voids

If you read through Autodesk documentation for Revit and the best practices document that they published some years ago you'll find casually mentioned recommendations to "avoid voids" because they will negatively impact performance. That turns into a conversation overhead later, "Never ever use voids in families!!" Hmmm...

Recommendations are wonderful, wonderful when they actually mean something meaningful. A warning like don't use more than six voids in a family. That's specific, I better not use more than six voids or something bad will happen to me, and my project. Then again I might just get wild and create families with seven voids just to make other people mad and drive project performance into the gutter?

I've read and heard similar warnings and recommendations for using formulas, "Avoid using too many formulas in your families". Is eight too many or seven hundred? I'm guessing seven hundred is worse but what about twenty five or forty five. Have we crossed into unsanctioned and untenable content now?

I'd love to see more practical recommendations that quantify things better. I seriously doubt a family with several voids is really going to harm a project, even if there are five hundred copies of the family in the project. I suppose we need to turn the Revit "masses" loose and test all kinds of situations to come up with more specific recommendations?

In the meantime I'm going to keep being careful to avoid voids all while wondering how many voids to avoid...


Alfredo Medina said...

At least, in regards to arrays of non-nested items, there seems to be a specific number that triggers warnings about performance. That number is 11. Revit never complains for any number of items up to 10. But as soon as I enter 11, Revit shows the warning: "This array contains multiple copies of some identical geometry. Performance might be improved by using a nested family and arraying copies of its instances." The interesting thing is that Revit complains at 11 regardless of the type of object, solid or void.

Erik said...

Seven’s the Key Number Here. Think About it. Seven Doors. Seven-Eleven. Seven Little Chipmunks Twirling on a Branch, Eatin’ Lots of Sunflowers on my Uncle’s Ranch. Seven!

Jeff Hanson, Autodesk said...

I can't give a definitive answer to: "How many is too many?" But I can shed some light on the problem since I was in the room when the documentaiton you mention was discussed/authored. When voids are used to create geometry more "faces" need to be calculated which can slow performance.

Imagine a simple cube solid form, this form needs 6 "faces" to be calculated. Now imagine a void rectilinear type of form intersecting the original cube leaving a "donut" type solid. Now 14 "faces" need to be calculated. 6 for the original solid, 6 for the intersecting void, and 4 for the resulting interior donut faces.

If you make the same exact shape using a sweep only 10 "faces" are calculated. The 6 for the exterior of the donut and the 4 for the interior of the donut.

So the basic idea here is the more faces that need to be established the slower things will perform. So using voids to cut geometry will ALWAYS increase the number of faces simply because the faces of the solids and the voids as well as the resulting intersecting faces need to be calculated. In small amounts you will probably not notice the performance hit, but the more voids you use the more chance you have at noticing the performance reduction. Sometimes using voids makes making the geometry much easier tahn if created completly from solids, but they will cause some preformance reduction.

I hope that sheds some light on the advice in the documentation.

Jeff Hanson, Autodesk said...

Oops, my math was off in my example above. The donut form created with the void is 16 faces not 14. The same donut created as a sweep is still 10 faces. Sorry about the math mistake.

Steve said...

Erik - I can count on you to add value to any post!

Jeff - Wrote this post thinking - I am poking Jeff in the eye with this one, thank you for the factory insight!

A tangent: I often think that the 2D versus 3D being visible in views seems a bit counter-intuitive to think that a file with many more elements - one using 2D lines, masking and such - will outperform one with fewer, but 3D only elements.

Seems to me if a family is simpler - has fewer elements - that it should outperform one that is more complicated by adding 2D only elements to avoid displaying 3D forms.

Autodesk Seek is quite particular about this and I think it is over generalized.