Thank you for reporting this. This is a tricky one as the Rhino UI is not really aware of the location of the shade unless it is a building shade or an aperture shade. I agree that this can be really confusing.
I assigned this one to @mingbo so he can share his thoughts. Meanwhile it will be helpful if you can share a simple example with us.
Hi @loicw, the setting for indoor vs outside is only meaningful for apertures that have been added to a room. Otherwise, you will have to ensure the aperture’s normal which is used for generating indoor/outdoor shades.
@mingbo, I checked the model and the apertures are facing inwards. Doesn’t the Rhino plugin automatically fixes the normal direction for the aperture?
So Rhino plugin only tries to fix apertures’ normal when they are adding to a room. However, after apertures are added to rooms, users can edit or change the aperture’s normal, and the rhino plugin won’t complain about it.
Hi @loicw, did you use our clean sample to create this model? or using one of the completed models and making editions on top of it? I will need to know how this model was created with these wrong aperture normals, and try to replicate this issue on our side.
Since the inward-facing apertures are not technically invalid in HBJSON I think your approach makes sense. That said, we probably need a command to allow the user to recompute the geometry to fix such issues for models that are created outside the Rhino plugin.
I believe the model is created using the Revit plugin which doesn’t check for the normal direction. The fix happens during the translation of the HBJSON file to simulation models. It’s fine there but it can be really confusing for users inside the Rhino plugin. That’s why I’m suggesting adding a new command to help users to fix such cases.