[Radiance-general] genskyvec with HDR sky view?

[Greg Ward]

Hi Achim,

I apologize for being snippy in my response.  It must be because I am feeling a little out of depth on this topic, myself.  I am glad that Andy and others are willing to help, as they know more about it than I do.

It does help when you provide example inputs, commands you have run, and what was unexpected about your results.  Too many questions without specifics can be overwhelming.  If your mail was sent as HTML, it got stripped before getting to me.  I think our mailing list manager may be to blame.  Best just to compose in standard text format.

To create a sky that genskyvec will accept, it should be sufficient to take the output of gensky and replace the skyfunc definition with your colorpict modifier.  I don't think it cares about the primitive type (i.e., "brightfunc" versus "colorpict").

I agree that you should not use skymap.cal, which assumes local geometry.  A hemispherical source will not set the Px, Py, and Pz variables properly.

Cheers,
-Greg

> From: "Achim Geissler" <achim.geissler at intergga.ch>
> Date: June 1, 2016 1:08:31 AM PDT
> 
> Hi Greg,
> 
> sorry to be somehow seemingly rubbing you the wrong way - I can't remember
> you ever telling anybody else simply to "give up" :o( . It is definitely not
> intentional (and I may note here that I am not a native English
> speaker/writer).
> 
> The formatting was O.K. with html mail format. Whatever.
> 
> The Photosphere stuff was simply to try to give some information on the HDR
> in respond to your statements in regard to same (kind of "prove" that it is
> actually a Radiance readable HDR ...).
> 
> The comments on orienting the HDR are noted. I accept that if I do it right,
> it should be correct  ;o)
> 
> I wasn't planning to rewrite genskyvec.pl, but you have me confused on how I
> should "prepare a sky file it will accept" - which is clearly my goal -
> without understanding at least partially how it works / what the data flow
> is / what it needs.
> 
> Actually, the number of the warnings increased significantly and no result
> was obtained. With skyfunc_hdr a (not very useful) result was generated with
> "some" identical warning messages.
> 
> @Andy: Incidentally, this is in regard to one step before tackling genskyvec
> again, I am trying to generate a view of a scene via "sky_glow source sky"
> based on the HDR ... the scene has a ground plane, but does have a "hole"
> between this and the sky (which works with "normal" skies). I'll try your
> suggestion for the sky definition, thanks!
> 
> Skymap.cal is
> ===
> u = 1 - (0.5 + DDx *r);
> v = 0.5 + DDy *r;
> 
> r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);
> 
> DD = sqrt(DDx*DDx + DDy*DDy);
> 
> DDy = Py*norm;
> DDx = Px*norm;
> DDz = Pz*norm;
> 
> norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);
> ===
> 
> I'll go back to RWR again and see what I can learn.
> 
> Thanks.
> 
> Best
> Achim
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Greg Ward [mailto:gregoryjward at gmail.com] 
> Gesendet: Mittwoch, 1. Juni 2016 00:18
> An: Radiance general discussion
> Betreff: Re: [Radiance-general] genskyvec with HDR sky view?
> 
> Hi Achim,
> 
> I'll answer inline again, making a bad formatting job look even worse....
> 
>> From: "Achim Geissler" <achim.geissler at intergga.ch>
>> Date: May 30, 2016 8:05:25 AM PDT
>> 
>> Hi Greg,
>> 
>> thanks for the pointers. I am afraid, though, that I was unable to 
>> really make heads or tails of them.
>> a) HDR file (Photosphere)
>> 	i, the (test) HDR gives min/max values in falsecolor view of 39 to 
>> 2900, whatever the unit, there
>> 	ii, it gives histogram min/max values  for Luminance of 34.8 to
>> 4.43E+06
>> 	iii, it does not seem to be clipped
> 
> I don't know what (i), (ii) and (iii) refer to, if anything.  Are these
> particular processes you have tried?  If so, what are they?
> 
> Typically, falsecolor and Photosphere report photometric values (i.e.,
> radiance values times 179 lumens/watt efficacy).
> 
>> b) There is a sun (albeit behind a thin cloud cover). Simply adding a 
>> sun definition to my sky description did not really change anything,
> though.
>> Also, at this point I do not know which r,g,b radiance values to use 
>> for the solar "light" material and do these influence the result? And, 
>> actually, how to exactly position the HDR so that the sun positions tally.
> 
> If you have your sky turned the right way around, so that the Z-axis points
> up, Y-axis points north, and X-axis points east, then positioning the sun is
> a matter of running gensky with the appropriate date/time and global
> position parameters, and extracting the description it generates.  You can
> adjust the solar radiance values to match the global-diffuse measured that
> day using the -R option to gensky.
> 
>> c) I took a look at the genskyvec.pl script, however, I am not 
>> perl-literate so that is a bit difficult. I seem to be missing out on 
>> where this script >could< use values from the HDR file to generate the 
>> sky vectors. Part of the code seems to be a copy of the setting up of
> patches from reinhart.cal.
>> Also, the "skyfunc glow skyglow" and "skyglow source sky" are written 
>> to the
>> (an) octree in the script. Can I ignore that? Or does that let me 
>> leave these definitions out of my sky description? Which definition has
> precedent?
>> I can't really see where the "skybright.cal" values from a standard 
>> gensky sky would come into play - this should be what is replaced by 
>> values from the HDR?
> 
> I'm not suggesting you rewrite genskyvec.  Rather, I'm suggesting that you
> prepare a sky file it will accept and run it on that file.  If this doesn't
> make sense, then I suggest you give up.
> 
>> d) using the sky description as below but with "skyfunc" gives
>> rpict: warning - compute error for colorpict "skyfunc"
>> rpict: Division by zero
>> when trying to generate a view of a scene.
> 
> I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
> file should cause new errors.  You must have done something else, or the
> original run would have generated the same errors.  I don't know what's in
> "map_sky.cal", which is the likely cause.
> 
>> I must admit the flow of data (input / output) in all the definitions 
>> is a bit of a mystery, for me. I did find a kind of description for 
>> colorpict in p_data.c, but that didn't really help, sadly. Looking at 
>> your code, I get the feeling I am not literate in any programming 
>> language ... :o(
> 
> Well, it's not particularly transparent, I will grant you.  There's this
> back-and-forth between the ray tracing and the scene description, such that
> when a material is intersected, it queries its modifiers, which calls back
> to your map_sky.cal file in a rather convoluted fashion.
> 
> You should look through Chapter 4 of "Rendering with Radiance."  Starting at
> Section 4.1.4, we talk about how the interaction between rendering and .cal
> files operates.
> 
>> If you (or, of course, anyone else out there that has done this 
>> before) can give any further help or tips, it would be much appreciated.
>> 
>> Best
>> Achim
>> 
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Greg Ward [mailto:gregoryjward at gmail.com]
>> Gesendet: Samstag, 28. Mai 2016 01:27
>> An: Radiance general discussion
>> Betreff: Re: [Radiance-general] genskyvec with HDR sky view?
>> 
>> Hi Achim,
>> 
>> I wouldn't call what you are trying to do "easy," even if others have 
>> done it.  Your HDR file has to be in the correct units or scaled by 
>> the right amount to get calibrated radiance values, and even then, the 
>> sun is usually out of range(clipped) and won't be properly sampled if it
> is a clear sky.
>> 
>> As you noted, such a sky cannot be given as input to genskyvec, which 
>> expects a very specific set of primitives output by gensky or gendaylit.
>> Specifically, you need to name your colorpict pattern "skyfunc" and 
>> add a solar source if the sky is sunny.  You could try to modify your 
>> description to match, but you'd have to look at the Perl script 
>> src/util/genskyvec.pl to figure out how to satisfy the input requirements.
>> 
>> Once you have a sky description, you can use rtrace with the -I option 
>> to compute hemispherical irradiance, from which you can create an 
>> adjustment factor to apply to your glow based on horizontal irradiance.
>> 
>> It's all possible, but the details are not very straightforward.
>> 
>> Best,
>> -Greg
>> 
>>> From: Achim Geissler <achim.geissler at intergga.ch>
>>> Date: May 27, 2016 12:29:35 PM PDT
>>> 
>>> Hi all,
>>> 
>>> after searching high and low without clear results apart from a lot 
>>> of
>> pointers that “everybody seems to be doing it” (so it should actually 
>> be easy and I am probably missing the forest due to seeing trees, as 
>> they say) a short question: The goal is to use HDR (fisheye) views of 
>> the sky for radiance calculations. All I could manage to date are 
>> pretty pictures with HDR skies. Ideally, the workflow would be “the 
>> same” as when using a sky from gensky or gendaylit. E.g., it would be 
>> nice to be able to generate the sky vectors (genskyvec) from the HDR 
>> sky view. Is that possible? How? Trying to simply pipe a sky 
>> definition along the lines of
>>> 
>>> void colorpict skyfunc_hdr
>>> 7 red green blue sky_image.hdr map_sky.cal u v
>>> 0
>>> 0
>>> 
>>> skyfunc_hdr glow sky_glow_hdr
>>> 0
>>> 0
>>> 4 1 1 1 0
>>> 
>>> sky_glow_hdr source sky_hdr
>>> 0
>>> 0
>>> 4 0 0 1 180
>>> 
>>> into genskyvec didn’t work - well, would have been too simple (the
>> map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following 
>> approaches resulted in the “pretty pictures” (replacing “source” 
>> above)
>>> 
>>> sky_glow_hdr bubble sky_hdr
>>> 0
>>> 0
>>> 4 0 0 0 2000
>>> 
>>> or
>>> 
>>> !genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000 
>>> -500
>>> 
>>> A further topic will be a “calibration” of the HDR sky views - we 
>>> have
>> global horizontal and diffuse horizontal radiation values available. 
>> The current idea of a (possibly slightly rough) method of calibration 
>> would be to use the HDR sky to calculate the corresponding sensor 
>> value with radiance and “somehow” introduce a scaling factor into the 
>> HDR sky such that the measured and calculated global horizontal radiation
> values tally.
>>> 
>>> Thanks for any hints & ideas!
>>> 
>>> Best
>>> Achim