Hi, I have been struggling with something that should have been quite simple to be honest… I am trying to mirror windows in both directions simultaneously. I can’t just flip them, as we have removed all flippers from our families (in an effort to make them idiotproof).
The problem with mirroring is that it always works in the same direction, no matter the direction of the plane I define as an input. So here are my planes:
and I am trying to mirror elements sequentially against each of them:
However, the second mirror just brings them back to their original state. Before introducing grouping for each individual element, I would get this message: “Can’t mirror an instance without its host”.
This is why I am grouping and ungrouping the elements, as suggested in this thread: Solved: Cannot mirror door without its host using MirrorElements - Autodesk Community
Here are the graph and a sample file 
:
Test-2.dyn (64.5 KB)
Sample.rvt (5.3 MB)
@danail.momchilov ,
i did here a sample, it works very well!
@Draxl_Andreas thank you for your suggestion! but you are actually doing something different, not what I was trying to achieve. You are copy mirroring them against the 45 degree plane. I am trying to mirror each window against its own origin, changing both their flip and facing direction
Well - Flipping isn’t mirroring as you have found out. There is a Mirrored property, a flipFacing property and a flipHand property. I haven’t looked at it too closely, but the problem might be the plane you are using to mirror. I’m guessing you would want to use the centerline of the host, rather than the center of the family.
For a quick check to make sure you can mirror, just do a manual mirror using the wall centerline. if that works, then mirror plane is probably the issue. If it doesn’t, then there is probably something about the family.
Out of curiosity, what’s the reason for avoiding flip controls? I’m not sure that is going to make things more idiot proof. What’s the end goal in your process?
Just as you’ve mentioned - flipping isn’t mirroring. Avoiding the flip controls is quite commonly used actually, in order to avoid mistakes when creating specifications. It’s a wide-spread issue, in case you are not aware of it, you could check this article: How reliable is the data in your Revit model?. Long story short - if you flip a family instance (or mirror it), it does not appear mirrored in the legend component afterwards, which is causing mistakes. This is why you need to have a mirrored family and place that one instead of mirroring or flipping elements. Since flippers are too handy to use, a lot of offices are trying to avoid them in that manner.
This small piece of graph is actually a part of a larger one, meant to do just that - identify mirrored windows and automatically replace them with the correct type and mirror them back. However, being able to mirror in both directions is essential in order to cover all use cases 
And yes, manual mirror works in both directions. My planes are correct, you can see on the screenshot. I will try using a plane, based on the host, but I really don’t see what would be the difference, especially for the left / right mirror, which is the problematic one, as it should be perpendicular to the host and located in the center of the window anyway.
Thanks for the explanation.
My approach is different. We use the flip controls and mirrored properties to assist with scheduling rather than changing the model. Much like the way we handle doors. I think the article you are referencing is alarmist and doesn’t really understand the flip controls, It heads down a path that makes things harder, rather than easier with some bad assumptions.
Using the example of doors, from the mirror and flip information, you can determine if the door is RH, LH, RHR, LH - and then feed that into a schedule.
With windows, the flip controls are easily used to programmatically make sure all of the windows face the exterior correctly. From there we can use the flipped property and the mirrored property to determine if the window is a standard window or opposite hand of the basic type.
Revit already manages mirroring and flipping. By taking OUT the flip controls, you actually make the problem harder. (The best way to solve a problem in the first place is to mot create one to start with.) Note the diagram below. The Flip facing and mirroring along the wall centerline are working together. Change one - the other value is changed. So, there is no conflict.as long as all the windows face out. Just use the flip properties and it will reset the Mirror back to False automatically. MUCH simpler Revt is doing the heavy lighting for you. if you take out the flip controls, then when someone places a window on the wrong wall face (inside) the only way to correct it is mirror it twice - tedious.
To un-mirror all windows? Keep both flip controls. Set both HandFlipped and FaceFlipped to False. Done. That’s an easy program to write. Way simpler than what you are attempting.
We use the HandFlipped property to tag and schedule the windows. Why shouldn’t the designer be able to flip a window? Saves a lot of content creation time. One family to rule them all. They Just get tagged A.1 and A.2 with A.2 shown in schedule and legend as opposite hand.
Rule of thumb:
- If the window is symmetrical, it only needs a flip face control.
- If the window is asymmetrical, it needs a flip face and flip hand control.
I get what you are saying and it makes sense until you try to include any type of graphical information to assist your schedules. If you have a window that is an OFF (where O stands for operable wing and F for fixed), by mirroring it, you would get FFO, while in the legend component you would place on the spec, one would still see the original OFF, which is just a mistake and mistakes cost money, as simple as that
For sure, there is no need to overcomplicate things for people in the office, which is why we are automating the task of identifying mirrored / flipped windows and replacing them with the correct family.
Anyway, thank you for your in-depth remarks, but I believe we are going further away from the original topic. This is a separate discussion already
We use nested/shared windows for ganged units. Both the ganged unit and the individual units get tagged on the elevation. Redundant - maybe - but very lar clear. And we’ve never had an issue with just saying “A2 - Opposite” Hard in the legend.
We don’t tag windows in plan - that’s where a lot of firms get in trouble.
The contractor only looks at the plan and schedule and screws things up. By only placing window tags in elevation - we force them to look at the actual elevation and location of the window - as they should.
We’ve never had an issue.
Yeah, I got what you are saying. I believe using only schedules to show a window spec and also mentioning which ones should be considered as their mirrored twin is far away from ideal and shows low data quality both in terms of the model and the office standard. Not to mention the windows producers, who would actually want to see a back side elevation for each window, at least in our country. I am still glad that works for you, but it really wouldn’t for us. And really, this is a whole different topic as mentioned already
Just found a simple, but really elegant solution 
posting it here to whoever might find it useful
I realized I could just change the family types to all the windows with a ‘dummy’ family, having the flippers turned on. Then flip those dummy families in both directions (or just one) and change them back to their original family type(or the one that is considered ‘correct’). Then I can have the original families flipped, without introducing flippers. That way, flipping is basically 5 lines of code:
t.Start()
for window in UnwrapElement(IN[0]):
window.flipFacing()
window.flipHand()
t.Commit()
2 Likes
I believe that’s a very limiting workflow to use for doors and windows, and it isn’t at all user friendly.
For complex families - say if you have a whole bathroom or a kitchen as a family where things like cabinet doors swing directions can’t be mirrored or two elements should always be at the same relevant positions and not flipped - I agree. You need to have a different family for the mirrored/flipped one.
For doors and windows though - usually it’s enough to have an instance parameter that shows if the family instance is mirrored or not, and assigning that parameter with Dynamo or a simple plugin is trivial.
1 Like
Hi, Viktor, what’s up! We don’t use this for doors, as for them particularly we don’t specify doors with a different hinge side as a different type. For them, having a parameter specifying whether the hinges are are on the left or the right side is enough.
For windows however, it’s quite problematic, cause you might end up ordering a completely different window type this is why we are trying to avoid it.
I honestly don’t think it’s needed for such thing as cabinets though. For any type of furniture just an interior elevation is enough, at least in terms of the way we do it. I guess it all goes down to how contractors work in each country, etc
By the way the other problematic category in terms of mirroring is Plumbing Fixtures, as you get connectors on the wrong side
Well in my experience the doors and the windows are more or less identical in the manner of how we show them and how we order them - each door type has a default parameter saying if it is a Left or right hinged, opening inwards or outwards and a plugin is assigning instance parameters based on whether the door is mirrored (or flipped). The windows additionally could have a n/a value if the window is not openable or has multiple panels opening in different dirrections - in the latter case just the mirrored value is enough.
For the cabinets - we don’t do this, that is where we have different types of the host family - the whole bathroom or kitchen.
It is due to the fact that things like washing and drying machines have doors that always open in one direction, as well as for ergonomic reasons or accessibility. Mirrored plumbing fixtures in the architectural model are usually not a problem since the MEP engineers have their own families placed in their project file.
###Update:
In any case I would prefer if possible to allow the architects to flip and mirror as much as they want.
I would also prefer If I can solve the problem with just assigning and pulling out the right data, than actually changing types or automatically mirror or flip elements.
One additional benefit to that is that when you have the elements in a group - you can still assign instance parameters (that vary by group instance), but you can’t change anything else programatically without ungrouping them
1 Like
Yes, I get it. We’ve had an extensive internal discussion on the topic and we have come to the conclusion we need to do that at this point, just for windows. For various reasons, mostly because of the way we make our window specs. It’s also not entirely up to me on how to handle our family library, I am trying to make our architects’ life better with what we have, considering the way we do it at the moment
1 Like
