Revit Architecture Forum
Welcome to Autodesk’s Revit Architecture Forums. Share your knowledge, ask questions, and explore popular Revit Architecture topics.
abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

Room Calc. Point - Window - Works only when facing inwards Revit 2024

17 ANTWORTEN 17
Antworten
Nachricht 1 von 18
Matt-Bishop
1000 Aufrufe, 17 Antworten

Room Calc. Point - Window - Works only when facing inwards Revit 2024

Hello,
I have noticed that in Revit 2024 If you activate Room Calc. Point for a window it will only calculate the room if the window is oriented so that the exterior of the window is facing inside the room.

I have tried to flip the Room Calc. Point in the family but is has no effect.
Does anyone have a solution for this that does not involve recreating the family/symbolic lines.

MattBishop_0-1687784990711.pngMattBishop_1-1687785020326.png

 

17 ANTWORTEN 17
Nachricht 2 von 18
barthbradley
als Antwort auf: Matt-Bishop

Works on my end.  Post your file.  

Nachricht 3 von 18
Matt-Bishop
als Antwort auf: Matt-Bishop

Here is the file. I was testing it in a new project. The rooms only show up in the schedule if the window faces the interior.

Nachricht 4 von 18
gokil.raja
als Antwort auf: Matt-Bishop

I hope you tried this flip option inside the family like mentioned. Please make sure either arrow ends of this calc. point lines lifted up from above reference level. otherwise lift the arrows height inside the family few mm's and load it again and try.

gokilraja_0-1687872017461.png

 

Nachricht 5 von 18
barthbradley
als Antwort auf: Matt-Bishop

I'm not clear on what the issue is?  

 

WDWROOMCALC1.pngWDWROOMCALC2.png

 

WDWROOMCALC3.png

WDWROOMCALC4.png

Nachricht 6 von 18
Matt-Bishop
als Antwort auf: barthbradley

We are trying to get the room name and area to show up in relation to windows and doors in a multi-category schedule so that we can automate natural light and ventilation calculations for rooms.

 

So for this case the window schedule solution does not work as it does not include doors.

The problem is the Room and Room Area parameters do not show up for the window or door if they are not facing inside the building (flipping the calculation point in the family does not work).

If you see in the multi-category schedule you posted only the windows facing the interior read the room all others are showing "Exterior" a room you created outside of the building.  We need that to read the room inside the building. We would prefer not to have to edit all of our fenestration families just to have the visual correct/make them all backwards.

Nachricht 7 von 18
barthbradley
als Antwort auf: barthbradley

I'm not clear what the Room Calculation Point has to do with it.   The RCP isn't even being used in the RVT posted.  You can turn it off in the window family for all it matters.   

 

 

Nachricht 8 von 18
GaryOrrMBI
als Antwort auf: Matt-Bishop

1) Use a window schedule instead of a multi-category schedule:
Windows have a "FromRoom" and a "ToRoom" value (just like doors) but multicategory schedules only have a "Room" parameter and that room parameter is controlled by the existence and orientation of the "Room Calculation Point)


2) turn off the "Room Calculation Point" in the family. If the family uses this then the FromRoom and ToRoom is fixed to the orientation of the window. If the family does not have this turned on then the ToRoom and FromRoom are independent of the facing orientation of the window (it is initially determined by the initial placement of the window, but is not fixed to it and you can change it in the schedule.

 

GaryOrrMBI_0-1687877141550.png

 

-G

Gary J. Orr
GaryOrrMBI (MBI Companies 2014-Current)
aka (past user names):
Gary_J_Orr (GOMO Stuff 2008-2014);
OrrG (Forum Studio 2005-2008);
Gary J. Orr (LHB Inc 2002-2005);
Orr, Gary J. (Gossen Livingston 1997-2002)
Nachricht 9 von 18
Matt-Bishop
als Antwort auf: GaryOrrMBI

Thanks for that tip, However we need windows and doors in the same schedule, so we can calculate the natural light and ventilation provided to the room, so we cannot use window schedule only to solve what we need, we need all glazed doors and windows to be scheduled per room. Due to this it is causing us some trouble with the error reported above.

Nachricht 10 von 18
barthbradley
als Antwort auf: Matt-Bishop

HA! I'm still scratching my head here. Why don't you just flip the Window?  

 

WDWROOMCALC6.png

Nachricht 11 von 18
Matt-Bishop
als Antwort auf: barthbradley

Yeah I'm out of ideas that's why I came here.
The doors are the biggest problem with flipping code/egress req., also miss representing windows on plans is visually unprofessional if they do not swing that way. (we are not using the ones in the example I posted that was just to show the issue). They also have the correct profiles in sections so the details are generated from the family, so it would cause allot of extra work.
The only thing I can think of is edit families basically from scratch at this point, make everything backwards but again that's going to take allot of time.

At this point its going to be easier/quicker for us to just manually calculate what we are providing and write it in text. I would rather use BIM practices through Revit, but it is what it is.

Nachricht 12 von 18
GaryOrrMBI
als Antwort auf: Matt-Bishop

Unfortunately I seem to be finding the same issue you are... regardless of which way the FroomRoom toRoom location pointer is flipped, the "Room" parameter in the multi category schedule always reports the outside face of the window... Seems like a bug may have been introduced to break the connection on the simple room location when doors and windows went from having a single "Location" point (like everything else that has that option) to having a "path" to introduce the form-to relationship and you just happen to be the first one to run across this scenario in the years that have passed since.

some of the math that you're looking at might be mitigated by having two schedules, both room schedules, one with an embedded door schedule and one with an embedded window schedule... while all doors and windows have the location property disabled so you can control ToRoom and FromRoom independently of the orientation of the door/window... Still a long way from perfect but a little closer. and the only remaining thought that comes to mind
-G
Gary J. Orr
GaryOrrMBI (MBI Companies 2014-Current)
aka (past user names):
Gary_J_Orr (GOMO Stuff 2008-2014);
OrrG (Forum Studio 2005-2008);
Gary J. Orr (LHB Inc 2002-2005);
Orr, Gary J. (Gossen Livingston 1997-2002)
Nachricht 13 von 18
ToanDN
als Antwort auf: Matt-Bishop

Turn off Room Calculation Point in the family and use a Window schedule.

 

ToanDN_0-1687886801827.png

 

p/s: turning on Room Calculation Point for Door and Window families is a bad idea unless your host walls in the project are really really thick.

 

 

Nachricht 14 von 18
GaryOrrMBI
als Antwort auf: GaryOrrMBI

I decided to test my theory and built a quick little function...

With a door in a given starting position:

 

When the door family did not have Room Calculation Point enabled

** Location: FromRoom | MEZZANINE C218
** Location: ToRoom | CHATTANOOGA ROOM 220
** Location: Room | MEZZANINE C218

 

Edited the family and Enabled the Room Calculation Point:

** Location: FromRoom | MEZZANINE C218
** Location: ToRoom | CHATTANOOGA ROOM 220
** Location: Room | MEZZANINE C218

 

Edited the family and reversed the direction of the Room Calculation Point:

** Location: FromRoom | CHATTANOOGA ROOM 220
** Location: ToRoom | MEZZANINE C218
** Location: Room | MEZZANINE C218

 

Notice that the Room value did not change after reversing the direction of the Room Calculation Point while the FromRoom and ToRoom did behave as expected and swapped

 

-G

Gary J. Orr
GaryOrrMBI (MBI Companies 2014-Current)
aka (past user names):
Gary_J_Orr (GOMO Stuff 2008-2014);
OrrG (Forum Studio 2005-2008);
Gary J. Orr (LHB Inc 2002-2005);
Orr, Gary J. (Gossen Livingston 1997-2002)
Nachricht 15 von 18
SteveKStafford
als Antwort auf: GaryOrrMBI

FWIW, in Revit 2024.0.20.20 (latest update) when I tested this the from/to values switched from "inside to outside" and back when I flipped the orientation of the RCp. So it appears to working as expected/intended in this version.

 

[edit: works in a window schedule...not multi-category]

 

 


Steve Stafford
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
EESignature

Nachricht 16 von 18
SteveKStafford
als Antwort auf: SteveKStafford

Hmmm, the window I was using the in the stock template has nested generic model families that also show up in the multi-category schedule and they change orientation but the window family itself doesn't.

 

I assume the Multi-category schedule that only offers Room as an addition parameter source is not differentiate between from/to and merely determining the room based on the exterior orientation of the family, which is defined by placement originally and only altered by flipping the window with the control, not RCp.


Steve Stafford
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
EESignature

Nachricht 17 von 18
GaryOrrMBI
als Antwort auf: SteveKStafford

As they say: The Devil's in the details...
Yes, the FromRoom/ToRoom works as expected in all three scenarios, but those values are only available in Door/Window schedules.
The OP was using Multicategory schedules. Multicategory schedules use the Room value that is common to all non-annotation families, but which does NOT behave as expected in Doors/Windows (it does not stay coordinated with either the FromRoom or ToRoom regardless of how you modify the orientation of the location pointer and is always fixed to the "Placement" side of the Family Instance)

-G
Gary J. Orr
GaryOrrMBI (MBI Companies 2014-Current)
aka (past user names):
Gary_J_Orr (GOMO Stuff 2008-2014);
OrrG (Forum Studio 2005-2008);
Gary J. Orr (LHB Inc 2002-2005);
Orr, Gary J. (Gossen Livingston 1997-2002)
Nachricht 18 von 18
SteveKStafford
als Antwort auf: GaryOrrMBI

I recall meeting someone who said that all his door/window families are Generic Model families (wall based) so they can be scheduled together. Said something like, "to hell with the stock categories...I need it to work the way I want!" Whatever he actually did seemed to be working for him. Details...details...

Steve Stafford
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
EESignature

Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.

In Foren veröffentlichen  

Autodesk Design & Make Report