[Radiance-dev] mingw rtcontrib (under windows)

[Gregory J. Ward]

Hi Francesco,

What is the date on your compile?  I notice I made a change on Oct.  
11th, where I paid more attention to zero normals on the input.  I'm  
just speculating, but if your view is a hemispherical fisheye, then  
all its border rays will be zero vectors, which could accumulate in a  
bad way using binary i/o and the earlier version of rtcontrib.c,  
perhaps causing some kind of buffer confusion.  I'm not exactly sure  
why it would show up in one mode and not the other, though.  Can you  
reproduce the problem under Unix?

-Greg

> From: Francesco Anselmo <pisuke at blueyonder.co.uk>
> Date: April 24, 2006 2:33:01 PM PDT
>
> Ladies & Gentlemen,
>
> I've hit this little problem with the mingw radiance binaries I've
> compiled last october.
> If I run this command to produce separate pictures for each light
> source:
>
> vwrays -ff -x 1024 -y 1024 -vf v3.vf | rtcontrib -ffc -x 1024 -y  
> 1024 \
> -ld- @render.opt -o c_%s.pic -m solar -m skyglow -m spot testSky.oct
>
> I get the following error:
> -----
> bin/rtrace: consistency - zero ray direction in localhit
>
> This application has requested the Runtime to terminate it in an  
> unusual
> way.
> Please contact the application's support team for more information.
> rtcontrib: fatal - rtrace process died
> -----
>
> If, instead of using floating point values, I use ASCII, like this:
>
> vwrays -fa -x 1024 -y 1024 -vf v3.vf | rtcontrib -fac -x 1024 -y  
> 1024 \
> -ld- @render.opt -o c_%s.pic -m solar -m skyglow -m spot testSky.oct
>
> everything works smoothly.
>
> Does anybody have any clue about it? I suspect it is directly  
> related to
> the mingw gcc, but it may be something else, you never know what  
> happens
> in Redmond ...
>
> Grazie!
>
> Francesco
>