Average illuminance of a polygon (v2) / rfluxmtx to sphere


#1

I’m trying to get an average illuminance of a polygon being lit by point lights
I’ve tried using the method proposed by Greg in this thread

and I end up getting an error “rfluxmtx: missing receiver surface!”

I’m not sure if its because I’m using rfluxmtx to cast rays “poly -> sphere” or if there might be some other reason? (didnt see anywhere that flux cant be done with spheres, but wouldnt be surprised because of the mapping involved)

scene:

materials.mat
void plastic whiteWall
0
0
5 1 1 1 0 0

void illum LightMat
0
0
3 1000 1000 1000

wall.rad
#@rfluxmtx h=u u=Z
whiteWall polygon wall
0
0
12
3 0 0
3 0 3
0 0 3
0 0 0

light.rad
#@rfluxmtx h=kf u=Z
LightMat sphere lightPoint
0
0
4 2 2 2 0.03

oconv -f materials.mat wall.rad > ./octree/scene.oct
rfluxmtx -V+ -ab 3 -aa 0.0 -ad 1048 -lw 0.00001 -dj 1 -n 16
./objects/wall.rad ./light.rad -i ./octree/scene.oct |
rcalc -e ‘$1=PI179$1’

in case I’m right about the sphere being the problem (since polys work), is there a method in radiance that converts mesh from sphere to polys, or is there a more elegant way of getting about this?


#2

Quoting the rfluxmtx man page:

In normal execution, only a single sender surface is sampled, but it
may be comprised of any number of subsurfaces, as in a triangle mesh or
similar. The surface normal will be computed as the average of all the
constituent subsurfaces. The subsurfaces themselves must be planar,
thus only polygon and ring surface primitives are supported. Other
primitives will be silently ignored and will have no effect on the cal-
culation.

In this case, you have given only a sphere, so “silently ignored” ends up generating an error since there are no valid sending surfaces. You could compose your sphere of triangles if you like, but this would create a different problem, that is determining the “average normal” for the sending hemisphere.

The basic restriction with rfluxmtx is that it calculates flux transfer between hemispheres. The sender cannot be a spherical emitter (nor can the receiver). In fact, you have reversed the usual roles in rfluxmtx, where the “sender” is a portal or illuminated surface, and the “receiver” is a (mostly) planar emitter or the sky. This is explained in the next paragraph from the man page:

In the receiver file, the source primitive is supported as well, and
multiple receivers (and multiple output matrices) may be identified by
different modifier names. (Make sure that surfaces using the same mod-
ifier are grouped together, and that the modifiers are unique and not
used elsewhere in the scene description.) Though it may be counter-
intuitive, receivers are often light sources, since samples end up
there in a backwards ray-tracing system such as RADIANCE. When using
local geometry, the overall aperture shape should be close to flat.
Large displacements may give rise to errors due to a convex receiver’s
larger profile at low angles of incidence.

If your source were planar rather than spherical, you could swap the sender and receiver roles in your example to compute the single-valued interaction. I think you could just use a ring source parallel to the illuminated surface and get the correct result if you divide the matrix coefficients by the cosine of the polar angle.

[I edited this response more than once…]