Aperture Offset in Rhino

I saw some old posts for Revit Plugin, but not for Rhino Plugin.

It seems that there is no feature of modelling window frames in Rhino Plugin for now. OK, I’m going to add window frames (WindowProperty:FrameAndDivider) in idf files for EnergyPlus, but I’d like to offset aperture surfaces by the width of the window frame in advance in Rhino.
For ASHRAE 90.1, U-factors of the Baseline case already account for frames, so no need to model frames in the Baseline case. The Proposed case should be modelled by either 1) Separated glazing & frames or 2) Aperture only with averaged U-factor of glazing and frame.

Ref: https://unmethours.com/question/80963/window-frame-input-option/

For the option 1) avobe, can I offset aperture surfaces in Rhino? For example, if I have an aperture surface with 1m wide and 1m high and I’m going to model frames with 0.05m wide later, I’d like to change the aperture surface to 0.9m wide and 0.9m high (while keeping the center of the aperture).

Any nature Rhino command is fine, but I don’t know it. Offset and Scale are not suitable.
And I often have hundreds or thousands of apertures in one model, so I’d like to offset all the apertures at once.

Hi @keigonomura, Thank you for the clear documentation.

I imagine you don’t want to use Grasshopper in this case. If that’s the case, then Rhino’s BoxEdit is probably the best option.

Make sure to select the Transform objects individually.

NOTE: This command is not compatible with the Pollination Rhino plugin. That means, that you will need to make these changes on the Rhino geometry before adding them to the rooms as apertures.

@mingbo, it might make sense to provide a command to adjust the size of the apertures for window frames.

@mostapha Thank you for your reply. Yeah, BoxEdit is not applicable to multiple objects, and it is suitable for only surfaces along X-axis or Y-axis. I think I need to somehow offset apertures with GH script.

Hi @keigonomura,

Hmm. Did you select the Transform objects individually option? It is actually applicable to multiple objects.

Can you share a screenshot of your geometry? I can help you with putting a GH script together.

@mostapha I mean, I should not edit multiple aperture surfaces with Transform objects individually because each surface has different size and different coordinates.
I should not use Scale for multiple surfaces as well because I want to offset the same width and height (e.g., 0.05m), not the same scale.

My colleage had a GH script, so it’s ok for now.

Thank you for your time.

Hi @keigonomura and @mostapha ,

Have you tried with the PO_RebuildAperturesDoors command? You can change the offset value and adjust the apertures.

@mingbo I didn’t know the command.

I tried with one aperture, but nothing seemed to change.
If I want to shrink the aperture, the offset value should be negative (e.g., -0.05), right?

Hi @mingbo, isn’t this value only used when then aperture is outside the parent face? In this case, @keigonomura wants to offset the existing valid apertures.

Hi @mingbo, isn’t this value only used when then aperture is outside the parent face? In this case, @keigonomura wants to offset the existing valid apertures.

Ha @mostapha, you are correct. I think the best way is creating correct geometries either in Rhino or Grasshopper before converting them to apertures.

I generally agree with this statement, but there is no easy solution with the Rhino native commands to achieve this. And using Grasshopper is not for everyone. In addition, I think @keigonomura provides a valid real-world problem that justifies adding a new command to OffsetApertureBoundaries.

I imagine we can use the same logic we use in the OffsetChildObjects command. The difference is that we use the aperture face itself as the reference for offsetting the aperture inwards.

Let me know what you think.

Thanks, @keigonomura .

I just wanted to respond to this:

… and make a note that we have full support for WindowProperty:FrameAndDivider in our model schema and core libraries. So it is possible to assign window frames to your pollination models right now. However, we have not finished exposing frames on the Rhino plugin UI so the way that you have to do this right now is a little convoluted.

Essentially, you would have to make the window construction in Grasshopper using the frame_ input of the HB Window Construction component like so:

custom_window_construction.gh (16.9 KB)

Then, you would save the JSON text string representation of the construction into the following folder:


Here’s an example of this type of JSON file:
triple_pane_w_frame.json (3.4 KB)

Then, the next time that you open Rhino, the construction with the window frame will show up in the pollination construction manager and be available to assign to geometry and constructionsets. When this type of construction with a frame is assigned to geometry objects, it will automatically add an EnergyPlus WindowProperty:FrameAndDivider object for each geometry as it is translated to E+.

If this is something you think you might use a lot, perhaps we can bump the exposure of window frames in the Rhbino UI a little higher on our priority list.