Roof Bearing Discrepancy with Invisible Walls

[Archnot-Boltz]

I just drew some 4/12 pitch Truss designated Roof Planes on an open front pole building with a relative rough ceiling height of 17'4". The front of the building is open, so I'm using Invisible Walls to  demarcate the open front (this is an existing conditions drawing). In the attached 3d Image (see also the attached plan file), the roof planes generate correctly on the 3 roof planes that bear on Regular Walls (17'4" clg hgt- Roof Baseline generates at 223.625"). The one roof plane that was drawn over the Invisible Wall, generates at a Roof Baseline Hgt of 104.75".  When I change that wall from Invisible to Regular wall, the Roof Baseline will generate at the expected height of 223.625". Why would there be such a discrepancy? One would expect the ceiling height of the room that's determining the Roof Baseline on the other 3 roof planes to cause the Baseline over the Invisible Wall to be the same.

 

If this is user error, then Chief's logic for drawing roofs is wrong. As a user since Chief'97, I don't understand why I would have such an unexpected result drawing such a simple roof. For me, this shows the need for Chief to allow the User to "Set a bearing height for roof planes, independent of ceiling or room heights which is limiting and has been an issue since before the X-Versions.

 

thanks for any comments or feedback.

 

Brad Boltz

 

InvisibleWallsRoofBearingDiscrepancyDrawing.zip

[Alaskan_Son]

Hey Brad,

 

I can see the problem you're having and can only offer these 4 notes (and I assume you probably already realize a couple of these)...

• When the wall is set to invisible, the roof reverts to building to the default ceiling height set for the current floor...not a solution, just an observation.
• You can get the roof to generate properly by drawing the roof plane before changing the wall to invisible
• You can obviously manually adjust your baseline height
• What I would probably recommend as the best solution...Make yourself your own special room divider wall type made up of one or more layers of insulation/air gap material (or other "gap" material type).  This way you can get an invisible wall without actually setting the wall to invisible and if you make yourself a single layer wall type like this and set the thickness to something like .01", you can also use it to define a structure with what appears to be a single line and without it changing sizes on you like the OOB Room Divider.  This is a super handy wall type to have and I recommend every user add one to their list of wall types.

 

[Archnot-Boltz]

Thanks Michael,

I do indeed know how to get around the issue by either raising my roof planes to match the other three correct ones and or temporarily changing the invisible walls to normal then changing back, which is what I've done since my posting.

 

I need to try your "Gap Material" method when I get a chance. That's a cleaver solution and use of the wall layers attributes. Probably a "Work-a-round"  but still a cool one that won't cause me to ***** and actually one I should use when creating "Frameless Glass" shower enclosures.

 

I still think that the behavior of the invisible walls is something that Chief should fix and I guess I should send it to Tech support as an issue. I can't imagine that it hasn't already been a requested fix but redundant requests only reinforce the issues. Thanks, again-Brad

[Kbird1]

I believe in this case it is because you have left the Default Floor height at 94 3/4" instead of  the 208 3/4 in the Room DBX , and the roof Plane is being built at the Default height over the Invisible wall ( plus heel height). If you change the Default Floor height to 208 3/4 , the Roof plane builds correctly by the look of it.... ( 1st pic)  why with invisible walls it does that I have no idea, especially since in this case the wall is completing a 208" high Room.

 

I assume there is a Beam across the opening of some sort , so a better way to do it maybe to use the normal wall with a HUGE Doorwasy between the Posts... or....2nd pic.

 

 

[Archnot-Boltz]

Was basically pointing out what I think is an inconsistent behavior in the program. I certainly appreciate the feedback.

Drawing is of As-is-Conditions.-bb