Hello,
My test room has an opening on the ceiling and a big one towards the outside. I have just daylight and
would need no glass or other for those openings that are just ‘holes’ in the surfaces. My question is, should one always replace those voids with ‘fake’ surfaces through the mkillum command even when a simple hole in a surface and not a proper window is needed?
If your opening is large relative to the space below, or you have direct sunlight coming in through the opening and reaching your interior, then you are best off sticking with more aggressive interreflection parameters and a standard rendering approach. This is because the beam radiation will dominate over the indirect radiation from the sky.
On the other hand, if you have a deep skylight well whose final aperture is much smaller than your ceiling’s dimensions and all or nearly all of the beam is captured by the well, such that indirect light is all that reaches your space, then you can place an invisible surface at the ceiling opening (not the roof opening) of your skylight and use mkillum to good effect. To make an invisible surface, use the “trans” type with 7 real arguments “1 1 1 0 0 1 1”. I’m pretty sure you can also just use “void” as the invisible surface modifier, but you’d have to try it to double-check. In either case, your surface should exactly cover the aperture at the level of the ceiling.
Thank you for you suggestions. Then the invisible surface would be needed in case of sole skylight. Just one more doubt, should I have to treat also ‘lateral’ openings, that is big openings piercing the walls, as invisible surfaces in case of sole skylight?
The general advice with mkillum is to use it for small openings or systems that scatter light into the space. If the opening is large and no light is being scattered, then it doesn’t really offer much benefit.
Just one more doubt. I have tried to follow the instructions described in the cookbook:
"To create the distribution for the window, run the following command:
$ mkillum -ab 0 < objects/window.rad scene.oct > tmp/iwindow.rad. A successful run will create two new files: tmp/iwindow.rad which is a modified version
of window.rad, modifying the material windowglass, and illum.dat with the calculated
distribution of the window."
I can see the new .rad file but not the illum.dat, is there anything I am missing?
Thank you for your help.
Is your virtual surface pointing towards the space interior (i.e., are vertices listed counter-clockwise as seen from inside the space)? Also, did you remember to include your sky and sun (if any) in scene.oct? If mkillum doesn’t detect any light entering through target surface(s), then no *.dat files will be created.
The sequence of commands I use is: $ oconv sky.rad outside.rad scene.rad > scene.oct
where sky is what comes from gensky and ouside is the geometry of the sky and the ground as to page 30 of the manual. The opening is not included as suggested by the cookbook (but I have also tried to include it), then $ mkillum -ab 0 < opening.rad scene.oct > iopening.rad
Oh, I guess the problem is that you are using a mesh to represent your virtual surfaces, and mkillum doesn’t know how to handle those. It only handles polygons, spheres, and rings, as mentioned in the manual page. It won’t dig into meshes or instances to find the geometry there. Really, there is no reason to create a mesh file for two polygons. You can either use obj2rad to convert it, or (better) recreate the rectangle as a single surface rather than a pair of triangles, which don’t really work as light sources, anyway. (The reference manual paragraph on the “light” material speaks to that.)
You’ve run into some important caveats early on in your explorations, and I can only apologize for that. It would be great to have a set of general guidelines with warnings about common pitfalls, especially surrounding the light source calculation, which doesn’t deal with many kinds of geometry, in the name of efficiency.
Thank you Greg for your specifications, I suspected it so I gave it a try turning my surface into a radiance geometry, I forgot to mention it in my previous message. But, unfortunately, with the same result. This is my opening.rad:
OK, it looks like your source polygon is pointing in the right direction, but you’ve told mkillum only to include geometry modified by “void” rather than “opening_m”, which is I assume what you meant to specify. (Sorry – I didn’t notice this in your first post). The rest seems OK.
I think it would have worked without the trans material and using “void” as the polygon modifier for an invisible surface. In many places in Radiance, surface modifiers are used to select geometry, and it’s always the final modifier that matters.