Can I set pitch factor for roof area?

Thanks for the feedback. This is on our list. We'll post here when it's ready, and you'll get notified 👍🏻.

Would this include linear slope as well?

Would be awesome if pitch or wall height or whatever could be implemented at the section level instead of the parent takeoff so that we don’t have to have 10 takeoff items for the same assembly with only one differing dimension.

Hi Mark & John.

@Mark We are discussing linear slope also, but just need to plan it properly since the distance of a linear slope could vary based on the direction of the slope. For example an L shaped linear with one leg longer than the other, it would be different lengths depending on if the slope is (from a top view) left to right, or top to bottom. We're open to input here on what would be the most useful.

@John We are planning to allow properties to be set at the section level (to override the parent takeoff), but our current thinking is this would not be our default recommended path because specific materials would be applied to the parent takeoff, and breaking it down at the section level, we just as well create a separate takeoff. For example: if you apply formulas to a wall for stud count, an 8' wall would have different materials from the item list used than the 9', etc. Our general line of thinking is to make it super easy to group these different wall heights somehow in your templates so it's easy to right click and toggle to different heights but with each height being tracked in a separate takeoff (same could apply for different slopes on an area, or different window sizes on point counts, etc.). Some kind of easy grouping of templates could make it quick to switch between and still keep a consistent structure. The moment we start applying specific attributes to sections that changes material calculations to the section level, it defeats much of the logic applying material quantities to the parent takeoff as a group. The primary purpose of grouping sections in a single takeoff is so they can share the same material calculations with maybe an occasional override somehow.

If no material quantity calculations are needed, and all you need is measurements, etc. I could see adding a custom property to a specific section working just fine, along with a custom report that breaks them out by wall height. The concerns I have above are primarily along the lines of material quantity calculations.

Heber,

If you implement the pitch factor as a scalar for the linear total (ignoring direction) then there shouldn’t be an issue with the takeoff running in different directions. Honestly, I cannot think of a use case for tracking which direction a takeoff is sloping—not without going the route of 3D modeling or something.

I understand your reservations about not working out how to implement section level materials. Admittedly, it would be tricky. As I imagine it, the parent takeoff would need to know when a sections’ properties or formula differ from that of the parent and then understand that it cannot include all section totals in the parent’s totals. But this is reducible to knowing when inheritance is broken and then knowing what to do when it is broken. Obviously, there are limitations to this based on convenience and the user’s ability to understand how this works.

The most desirable place to implement this sort of behavior, in my opinion, would be the joist/rafter tool when the only thing that differs is the pitch of the sections.

@John Thanks for the additional input. We will dig further into the linear slope.

Regarding your comment "...based on convenience and the user’s ability to understand how this works", this is a significant consideration.

Brief story:

I have something I call the "collection/folder problem". In the early days of Google Drive, they allowed files to be stored in "collections". A file could be stored in multiple collections at the same time which was kind of cool. As users on our computers, we run into this issue all the time where something could logically be stored in 2 or 3 separate folders at the same time, but we don't want 2 or 3 copies. Somewhere along the way Google ditched that idea of a file existing in multiple collections (at least visually in their UI), and it's just "folders" now. Now a file has a parent, and you can create "shortcuts" from other folders to the same file...but the file has a specific "home" that it lives in (it's parent folder). I can imagine permissions got very complicated when the file could exist in multiple places and had no single parent. I have a theory that they reverted back to folders due the the fact that the average user got overwhelmed by the collections the way they had it, although it was a very elegant system. We use this as a comparison internally to help us focus in making sure it's simple for the average user. It's a fine balance, but our general approach is to make so 80% of the users can use it easily out of the box, and the rest of the "advanced" features are possible, but out of sight for the average user by default. I use this "file/folder problem" as a comparison sometimes when we're discussing internally features for development. If we abstract the data too much, even though it may be very elegant, it may reduce usability for most users.

Heber,

What I meant by convenience is that it is convenient to describe an assembly that is “mostly like this, less a little of that, and some of this where there is no longer that.” And this is common sense since it is easier to describe something as a whole, subtract for a void, and add a little of something (for whatever reason) at the void than it would be to describe the the object alone without referencing the void. However, there is a tipping point when there are so many exceptions to a specific assembly that it ceases to be one assembly based on the convenience of describing it.

Perhaps I misspoke when I said it depends on the user’s ability to understand. As demonstrated above, it is common sense. The key is making it known that it works in the way one would expect and that it ceases to be efficient when the assembly varies widely.

I appreciate your efforts in making zzTakeoff accessible to all. Thank you for your hard work.

Thanks for the clarification John. I agree: the key is making sure users understand how it works. Thanks for all your input to help us improve. We're so grateful for the community participation here to help make zzTakeoff the best it can be.