[Radiance-general] IES files and MGF geometry

[Greg Ward]

Hi Axel,

Yes, as Randolph reminds me, LM-63 did have the geometry spec in there.  All I remember is that it was never supported by anyone.  At least we are using MGF in our XML specification for complex fenestration system BSDFs, so it's not a complete waste.

Regarding the local box correction, you could take out the third term "noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3" from the formula:

lboxprojection = (	noneg(abs(Px-Dx*Ts)-A2/2)*A3*A4 +
			noneg(abs(Py-Dy*Ts)-A3/2)*A2*A4 +
			noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3 ) / Ts;

I think that should work.

Cheers,
-Greg

> From: Axel Jacobs <jacobs.axel at gmail.com>
> Subject: Re: [Radiance-general] IES files and MGF geometry
> Date: November 5, 2014 8:57:01 AM PST
> 
> Hi Greg,
> 
> I only know about this MGF embedding from the ies2rad man page, and
> thought it might solve my problem:
> 
> " -i rad    Ignore the crude geometry given by the IES input file and
> use  instead  an  illum
>                 sphere  with radius rad.  This option may be useful
> when the user wishes to add a
>                 more accurate geometric description to the light
> source model, though  this  need
>                 is  obviated by the recent LM-63-1995 specification,
> which uses MGF detail geome-
>                 try.  (See -g option below.)"
> 
> This sounds rather more positive than the situation appears to be now.  Oh well.
> 
> As you say--I would need near-field for my bollard.  Thank for sending
> the projection formula.  With the NF-correction for boxes already in
> the code, would a square bollard (again w/o bottom and top) be any
> easier to describe?  A square imposter is still a lot better than a
> hovering crystal ball.
> 
> Many thanks
> 
> Best
> Axel