Stumped on a Room Boundary...

[twiceroadsfool]

RAC 2008, new project, non worksetted, only one phase of work, all in default "New Construction."

The room boundary is using the walls above (that only exist above the roof) as its definition, which is crazy talk, and i cant seem to figure out what i missed. Granted, part of that wall is the room boundary on the ground level (and at 4'-0", which is where i have room boundary height set... i tried the default setting, no help there either).

In the 3d image you can see that there is nothing else in the space there...

Am i missing something?

[bowlingbrad]

have you tried unchecking "Room Bounding" for the rear three walls of the turret? Did you use the linework override tool to get the dashed lines in the plan? Maybe that is grabbing the walls above.

[sbrown]

The problem is the roof. since revit now looks for a "top" to the room you can't have a roof in a room at below the calculation height.

[twiceroadsfool]

Scott-

But my calculation height is 4'-0", lol... Youre saying the flat roof on the building is the issue? Or the peaked roof on the turret?

[twiceroadsfool]

Okay, i tried deleting it... but that didnt work for obvious reasons. Once i deleted it, the walls attached to it drop back down to the ground.

I made both roof types non room bounding, i dont suppose that will help?

Nope...

Hmmm.....

[dbaldacchino]

I've had something similar happen in a mechanical mezzanine condition. I had a wall top on Level 1 attached to the roof (one level above mezzanine floor) and also attached to the mezzanine slab (making a "U" shaped wall in elevation). The room placed on the mezzanine was getting bound by this wall, even though it didn't cross the mezzanine. I ended up detaching and editing the elevation profile of the wall to solve the issue.

In your case, do those walls have their base set to Level 1and then you applied an offset or attached their bases to the roof? That might be the problem.

[twiceroadsfool]

Thats exactly what i dit, but i have to... unless i split the walls or- as you said- edit the profiles and draw them around the roof manually...

Ugh.

I left them for now. I wont need the Areas to report correctly until the end of the week. I needed the elevations today, LOL.

Thats makes me worry though, as i depend pretty heavily on Revits powerful rooms...

[Calvn_Swing]

"Revit's powerful rooms?" - I hope you're kidding!

Aaron, can you post that section of the model, I'm having difficulty replicating it, but would love to try and find a fix. Also, I'm curious how you use Revit's "powerful" rooms, as I've yet to find a use for the bloody things outside the obvious. They so much less than I expected, but perhaps I'm missing the boat here...

Thanks!

[Mark James]

Even though your walls are attached to the roof above, the origin of your walls is the same level as the other walls (check wall properties). This is what the room tool reads from wall properties to define the room area. Change the level for those walls to a level above and the room will "behave" itself.

[Scott D Davis]

They so much less than I expected, but perhaps I'm missing the boat here...

Thanks!
What were you expecting?

[twiceroadsfool]

Even though your walls are attached to the roof above, the origin of your walls is the same level as the other walls (check wall properties). This is what the room tool reads from wall properties to define the room area. Change the level for those walls to a level above and the room will "behave" itself.

While i understand what you are all saying... Thats absurd! Did this change in 2008 by chance?

This exact portion of a model occurs in two other models i have in 9.1, and i dont believe this was an issue. I may have overlooked it, as it wasnt important back then.

Calvn-

We use them for a ton of things: Besides the obvious (Room tags and finish schedules), we also use them for tracking leasing documents throughout our 775k SF project. Tentative lease line locations are used in the shell, and when we get official lines from the leasing agents, the date of import/communication/leasing package production are all stored in the room itself. That way any person on the team can go in and see whats tentative, whats locked in place, whats already been reconciled.

Plus, all of our leasing packages are in the same model, so when we go to do a fit out, the room carries all of its pertinent information over.

Shoot, about the only thing they DONT do that id like, is have the ability to idetinfy what AREA they are in, and to have ALL items in revit know their ROOM and AREA.

But, im not sure what else could be expected by Rooms.

Perhaps if all of the bounding elements could be isolated for some sort of analysis, that would be neat...

Back to the topic at hand- I can try to strip it down and post it, but im going to see if changing the walls level affects it, as several people have mentioned. I'll be very disappointed if thats the case...

[twiceroadsfool]

Well...

You guys were right about the walls. I had to split the walls where they need to "attach" to the roofs, and make them separate walls. That way i could raise their bases to the level above. IMHO, it kind of kills having the ability to attach the base of the wall to the roof. Id prefer it be modeled as one continuous wall, for ease of maintenance, but splitting the walls and raised their bases cured the funny room bounding issue.

[Calvn_Swing]

I'd send this in to Autodesk. A room should be able to define it's boundaries in 3D more intelligently than it does currently.

I hadn't thought of using rooms quite like you mentioned, it seems to me a clever way of using them in a manner they aren't really intended to address. Very neat.

My frustration is that they don't do some things they should do. Like having objects know what room they are "in" or associated with. Or, being able to link parameters in annotations to room information - the long standing request to give us a way to have door auto-number themselves by the room they are related to. Etc...

Anyway, point being I don't think your condition is the intended behavior of room volumes, and probably needs to be corrected by Autdesk.

[twiceroadsfool]

Good point, i hadnt thought of that.

Ill have to revive a backup to send it to them, but i'll file a support request anyway.

The rooms as Leasing elements is perfect, but with a few shortcomings: Having multiple document sets in one model is great, because it keeps everything live and perfectly coordinated. If the person handling the lease lines moves the demise wall, its obviously moving in the shell package too. Granted, that could work just as well with a linked file, but too often the leasing stuff drives the hard elements of the shell package. One big shortcoming is sheet numbers. The leasing packages have to have sheet numbers like "3F21 A2.0" because A2.0 already exists in our shell package.

This REALLY kicked us in the nuts when we did our most recent model, with multiple phases. We simply started using 1A2.1 and 2A2.1 for the shell package phases... but the 3f21 a2.1 obviously hurts when you have to stuff it in a section marker.

The other shortcoming is the inability to alter how rooms pick their boundaries. Our client is using exterior of certain walls and CL of other walls, and we can only do that with an area plan, which doesnt suit our needs for a variety of reasons. So (while the SF is still important to us), we have differeing numbers than the official lease lines... which is a struggle.

[Calvn_Swing]

You know, rooms just need to make leaps and bounds in terms of functionality. They are used for so many things in terms of describing legal conditions on documents to defining volumes to calculate energy modeling equations, etc...

I wish a room could accurately describe the exact volume of the space in 3D, and have a separate editable sketch element to describe the square footage of a space. You should be able to edit the two independently. It would also be cool if you could click on a room tag and "go to view" and be looking at a built in camera view at a specified height and perspective angle inside that room. It should know what objects bound it, and be able to schedule anything in those bounding objects in the room schedule. I could go on for hours (or pages) here...

Anyway, glad to know you're going to send it off. Sometimes I think the developers don't spend enough time on the forums to pick up on all these discussions, and so they miss some obvious glitches because no one submits them after they post here.

[Mark James]

While i understand what you are all saying... Thats absurd! Did this change in 2008 by chance?

This exact portion of a model occurs in two other models i have in 9.1, and i dont believe this was an issue. I may have overlooked it, as it wasnt important back then.

I ran a test in both 9.1 & 2008... same result.
Absurd? Well, I guess everyone's entitlied to their opinion.

[twiceroadsfool]

Interesting. I have the exact situation modeled in both, and in 9.1 the room fills in the space. Its very well possible something else is different in that situation though, and i did not notice.

I filed a Support Request seeking clarification on if this is intended behavior, and sent them the model.

Mark-

I didnt mean absurd as any kind of an attach on either the software or the opinions of people here, but it seems to me that an elastic element such as a room, which gives you the opportunity to specify at which height it seeks a boundary, should do so by extending its limits until it hits an object specified as room bounding. I personally do find it silly that an object which does not even reside physically inside the building, divides room elements strictly because its base level is set to the same level as the Room Objects.

Thats all that i was surprised by. In the end, not a big deal... Just (in my opinion) surprising.

[Steve_Stafford]

...Like having objects know what room they are "in" or associated with...Many objects do know what room they are in. Rooms just don't "know" what things are in the room. A furniture schedule can include room data but a room can't report furniture data. It just goes to assumptions about how data is reported. A furniture installer is probably more interested in a schedule that lists their furniture and includes the room name/number than looking in a room schedule for furniture. Potayto...potahto...a simplistic example but that is the operating assumption at present.

Now ceilings ought to know what room they belong to, except it isn't so simple since not all ceilings are actually part of a single room. Sometimes our "simple" requests are anything but...

[twiceroadsfool]

I'd send this in to Autodesk. A room should be able to define it's boundaries in 3D more intelligently than it does currently.

Thought i would update:

Revit Support and i have been emailing back and forth since yesterday, partyl because i poorly articulated what exactly the problem was, hehehe.

I was able to convey the concern finally, and they passed it on to development to take a look at.

[tamas]

Thought i would update:

Revit Support and i have been emailing back and forth since yesterday, partyl because i poorly articulated what exactly the problem was, hehehe.

I was able to convey the concern finally, and they passed it on to development to take a look at.I just received the bug report from support a few minutes ago. I can confirm that the problem is caused by the turret walls having an "L-shape" due to the attachment.

To make an "L" shaped wall, it is better to edit the elevation profile of the wall. Otherwise the vetical edge of the L will not join to other walls. Rooms handle edited profiles better as well.
The "split-the-wall-to-remove-the-need-for-the-L-shape" workaround is reasonable as well.

I am sorry for your troubles. Please do not hesitate to send such issues to support. We have limited resources and need to know how important these problems are. This particular problem is fixable in our current implementation, but it is a sizeable amount of work and it was so far prioritized lower.

Thanks for understanding.

Tamas

[twiceroadsfool]

Thanks for the quick reply!



Rooms handle edited profiles better as well.
The "split-the-wall-to-remove-the-need-for-the-L-shape" workaround is reasonable as well.


Thanks for that... I had no idea Revit Rooms would favor one over the other. I tend to go the other way (try to shy away from using Edited Profiles for such tasks) simply due to simplicity. Knowing that rooms like them better, i will have to give that a try. Perhaps in the profiel sketch i can click the roof top and lock it? I'll try that.

Thanks again for looking in to it so quickly...

[Steve_Stafford]

Aaron, Tamas et al...thank you for a perfect thread! Problem described, discussed, submitted, discussed, responded and "resolved" even if only a recommendation for now. That and gleaning a potential best practice tidbit from someone on the inside.

Tamas, thanks for taking time to respond HERE, it is very important to us that this kind of personal interaction and response occurs whenever possible. Even if we may not be happy about the information imparted we can't deny that a response is an answer! :smile:

Thanks Again!!!