"MichaelJF" <mi-### [at] t-onlinede> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> >
> >
> > I am curious to see what you can achieve. I have not tested Rune's code
> > in a lightning setting. Maybe it is not good for that. If time allows, I
> > shall have a few experiments.
> >
> > Thomas
>
> May be I will use them as a comparison later. First I will test the other
> approach. If you will try the sample files be sure to add assumed_gamma 1 to the
> scene. Without I saw nearly nothing.
>
> Michael

Meanwhile I have implemented the first stage to construct a "leading" bolt (in
2D). The approach is very slow but first results looked promising. But now I
have to find a work around to compensate for the very high epsilon POV uses.
With a 64bit machine 1.69851e-013 is not zero, but POV treats it so. POV-eps
seems to be somewhere at 1.0e-5 or 1.0e-6 which is unacceptable completely
nowadays. I and others have experienced problems with this historical setting in
the past. Most likely one only has to change a constant within a header file but
no one dares to do so. And the problem is known...

Sorry, I'm a little bit frustrated having lost a days work due to this issue.
Take it serious but not too serious ;-) May be there more dependencies I cannot
judge.

Best regards,
Michael

Post a reply to this message

> "MichaelJF" <mi-### [at] t-onlinede> wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>
>>>
>>> I am curious to see what you can achieve. I have not tested Rune's code
>>> in a lightning setting. Maybe it is not good for that. If time allows, I
>>> shall have a few experiments.
>>>
>>> Thomas
>>
>> May be I will use them as a comparison later. First I will test the other
>> approach. If you will try the sample files be sure to add assumed_gamma 1 to the
>> scene. Without I saw nearly nothing.
>>
>> Michael
>
> Meanwhile I have implemented the first stage to construct a "leading" bolt (in
> 2D). The approach is very slow but first results looked promising. But now I
> have to find a work around to compensate for the very high epsilon POV uses.
> With a 64bit machine 1.69851e-013 is not zero, but POV treats it so. POV-eps
> seems to be somewhere at 1.0e-5 or 1.0e-6 which is unacceptable completely
> nowadays. I and others have experienced problems with this historical setting in
> the past. Most likely one only has to change a constant within a header file but
> no one dares to do so. And the problem is known...
>
> Sorry, I'm a little bit frustrated having lost a days work due to this issue.
> Take it serious but not too serious ;-) May be there more dependencies I cannot
> judge.
>
> Best regards,
> Michael
>
>
The epsilon value for 32 and 64 bits CPUs is the same as both have 64 
bits FPUs.

The epsilon value used by POV-Ray is larger due to some conciderations, 
like the need to raise some values to the third power in several places, 
and some times even more, 1e-6^ 3 = 1e-18...

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
>
> The epsilon value used by POV-Ray is larger due to some conciderations,
> like the need to raise some values to the third power in several places,
> and some times even more, 1e-6^ 3 = 1e-18...

Thanks for the explanation, I feared for that. Meanwhile I remedied my issue
with additional storage and premultiplying all values concerned a little bit. As
far as I can judge so far, this approach can yield a fine result in 2D with POV
but one needs a lot of patience since only a brute force algorithm can be
implemented with POV. In 3D one will need a compiler and pointer structures to
overcome the space and time requirements.

Best regards,
Michael

Post a reply to this message