Alain napsal(a):
> Jan Dvorak nous apporta ses lumieres en ce 2007/11/13 00:25:
>> Alain napsal(a):
>>> Jan Dvorak nous apporta ses lumieres en ce 2007/11/11 05:48:
>>>> Hello,
>>>>  When I use double_illuminate in a radiosity scene it does nothing 
>>>> (it does get double_illuminated by light_sources).
>>>> Here's a scene to illustrate:
>>>>
>>>> default{finish{ambient 0}}
>>>> camera{location <3,4,5> look_at 0}
>>>> polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate  z}
>>>> polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate -z}
>>>> background{rgb z}
>>>> global_settings{radiosity{}}
>>>> sphere{-y/2,0.5 texture{pigment{rgb y}finish{ambient 10 diffuse 0}}}
>>>> light_source{y/2,rgb x}
>>>>
>>>> Is it a bug or it is intentional?
>>> Working as expected.
>>> The polygons are double_illuminate be the light_source (red), whitch 
>>> contribute on both faces.
>>> They are lighted in blue from the background, giving that magenta tint.
>>> The faces near the high ambient grees sphere are illuminated in 
>>> green. They are also affected by the other polygon, lighted in red, 
>>> and, weekly, the blue background.
>>>
>>
>> As for MegaPOV 1.2.1 @ WinXP the front square doesn't get doubly 
>> illuminated by the green sphere. Can you post your configuration, please?
> It's not double_illuminated by radiosity, and sould'nt be.
> 
How come it shouldn't?

Post a reply to this message

Jan Dvorak nous apporta ses lumieres en ce 2007/11/13 10:09:
> Alain napsal(a):
>> Jan Dvorak nous apporta ses lumieres en ce 2007/11/13 00:25:
>>> Alain napsal(a):
>>>> Jan Dvorak nous apporta ses lumieres en ce 2007/11/11 05:48:
>>>>> Hello,
>>>>>  When I use double_illuminate in a radiosity scene it does nothing 
>>>>> (it does get double_illuminated by light_sources).
>>>>> Here's a scene to illustrate:
>>>>>
>>>>> default{finish{ambient 0}}
>>>>> camera{location <3,4,5> look_at 0}
>>>>> polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate  z}
>>>>> polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate -z}
>>>>> background{rgb z}
>>>>> global_settings{radiosity{}}
>>>>> sphere{-y/2,0.5 texture{pigment{rgb y}finish{ambient 10 diffuse 0}}}
>>>>> light_source{y/2,rgb x}
>>>>>
>>>>> Is it a bug or it is intentional?
>>>> Working as expected.
>>>> The polygons are double_illuminate be the light_source (red), whitch 
>>>> contribute on both faces.
>>>> They are lighted in blue from the background, giving that magenta tint.
>>>> The faces near the high ambient grees sphere are illuminated in 
>>>> green. They are also affected by the other polygon, lighted in red, 
>>>> and, weekly, the blue background.
>>>>
>>>
>>> As for MegaPOV 1.2.1 @ WinXP the front square doesn't get doubly 
>>> illuminated by the green sphere. Can you post your configuration, 
>>> please?
>> It's not double_illuminated by radiosity, and sould'nt be.
>>
> How come it shouldn't?
Radiosity ignore double_illuminate, it never use samples comming from behind the 
surface.
You can fake it as follow:
default{finish{ambient 0}}
camera{location <3,4,5> look_at 0}
polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate  z no_shadow}
polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate -z no_shadow}
background{rgb z}
global_settings{radiosity{count 1000 error_bound 0.9}}
sphere{-y/2,0.5 texture{pigment{rgb y}finish{ambient 10 diffuse 0}}}
light_source{y/2,rgb x}
#declare Offset = 1.05;
polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate Offset*z
	finish{reflection 1} no_image no_shadow no_reflection}
polygon{5,x,y,-x,-y,x pigment{rgb 1}double_illuminate translate -Offset*z
	finish{reflection 1} no_image no_shadow no_reflection}

This is you original scene with the following changes:
Added no_shadow on the original polygons.
Added 2 reflective polygons just outside the original ones, with no_everything. 
That way, they reflect but don't show, don't have shadow and don't reflect on 
each other.
Increased count, less that 1000 and you get artefacts.
Had also to reduce error_bound.

-- 
Alain
-------------------------------------------------
Bend the facts to fit the conclusion. It's easier that way.

Post a reply to this message

Jan Dvorak <jan### [at] centrumcz> wrote:
> >> As for MegaPOV 1.2.1 @ WinXP the front square doesn't get doubly
> >> illuminated by the green sphere. Can you post your configuration, please?
> > It's not double_illuminated by radiosity, and sould'nt be.
> >
> How come it shouldn't?

This is meant to say that the POV code is written such that radiosity does not
use the double_illuminate flag, so it shouldn't be expected to act as such, not
that theoretically or conceptually it shouldn't (couldn't) be considered.

However, that brings up the question on whether it should or could be
implemented in future code (beta if it's very simple, patched versions for
those coding enthusiasts, POV4 beyond that)

Seeing as it's a feature that is present for traditional light sources, I don't
see why it shoulnd't be allowed to affect radiosity as well, but I don't know
how easy it would be to add to the source code, perhaps it's not a trivial
matter.  This would be for the coders out there to decide.

-tgq

Post a reply to this message

Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> Seeing as it's a feature that is present for traditional light sources, I don't
> see why it shoulnd't be allowed to affect radiosity as well

  A double_illuminate feature in radiosity would make it slower because
then each radiosity ray would need to be doubled (for each regular radiosity
ray a second ray would also need to be spawned on the other side of the
surface).

-- 
                                                          - Warp

Post a reply to this message

Warp napsal(a):
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
>> Seeing as it's a feature that is present for traditional light sources, I don't
>> see why it shoulnd't be allowed to affect radiosity as well
> 
>   A double_illuminate feature in radiosity would make it slower because
> then each radiosity ray would need to be doubled (for each regular radiosity
> ray a second ray would also need to be spawned on the other side of the
> surface).
> 
do you really mind? :-)

Post a reply to this message

> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
>> Seeing as it's a feature that is present for traditional light sources, I don't
>> see why it shoulnd't be allowed to affect radiosity as well
> 
>   A double_illuminate feature in radiosity would make it slower because
> then each radiosity ray would need to be doubled (for each regular radiosity
> ray a second ray would also need to be spawned on the other side of the
> surface).

True, but it also happens when you specify 100 samples instead of 50.

If being able to take double_illuminate into account in radiosity (it
seems that it makes sense, anyway) helps getting more realistic
pictures, it should be envisioned.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> If being able to take double_illuminate into account in radiosity (it
> seems that it makes sense, anyway) helps getting more realistic
> pictures, it should be envisioned.

  double_illuminate is not realistic. It doesn't correspond to any
physical phenomenon.

-- 
                                                          - Warp

Post a reply to this message

Warp napsal(a):
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> If being able to take double_illuminate into account in radiosity (it
>> seems that it makes sense, anyway) helps getting more realistic
>> pictures, it should be envisioned.
> 
>   double_illuminate is not realistic. It doesn't correspond to any
> physical phenomenon.
> 
It does correspond to any surface that is thin enough to be translucent 
but thick enough not to be transparent. A good example is a paper 
(although the light path translute-diffuse reflect-translute is much 
weaker than the direct reflection the double_illumination effect is very 
strong if the paper is backlit).
Try taking two pieces of paper, the bottom one having been written on. 
You only see the top one. Then backlight them - you can see clearly what 
is written on the bottom side, which means paper is either a bit 
transparent or a bit double_illuminated. Now lift the top one. You will 
see the bottom paper's projection blur srongly, which means that paper 
is translucent, not transparent. And that's what double_illuminate is for.
However, I do see a bit of unrealism:
- It's an object property. It should belong to a texture.
- It should be possible to regulare the amount of double_illumination. 
Right now it is 1:1.
   My idea is a back_diffuse keyword in the finish statement. 
[diffuse]*[direct lighting*]+[back_diffuse]*[backlight*]=total 
illumination. back_diffuse defaults to diffuse if double_illuminate is 
set and 0 if unset. It causes a warning if both appear.
*including radiosity
- Povray should consider every texture layer, not just the top one.
-- Also I think that the default inside texture shoud be the outside one 
*in the reverse order* (imagine gluing a few stickers onto a glass. 
Which one do you see from the back side, the top one?). Or even forbid 
interior_texture completely (it is more realistic but it reduces 
artistic possibilities). But that's another chapter.

Post a reply to this message

Jan Dvorak <jan### [at] centrumcz> wrote:
> >   double_illuminate is not realistic. It doesn't correspond to any
> > physical phenomenon.
> > 
> It does correspond to any surface that is thin enough to be translucent 
> but thick enough not to be transparent.

  No, it doesn't. Just take any material you want and compare its
illumination on the side facing the light and on the opposite side.
The illumination is totally different. With double_illuminate the
illumination on both sides will be *identical*. This corresponds to
nothing in nature.

  The only reason why double_illuminate exists in povray is because it's
so laughably easy to implement (it's a 1-liner: 1 single 'if' statement;
or more precisely, one additional condition in an existing 'if' statement),
and it can be used in certain situations to eg. alleviate some rendering
artifacts, as well as other purposes. It's not even intended to be a
physically accurate feature.

> A good example is a paper 

  Emulating the illumination on the backside of a paper in a physically
accurate way would be quite laborious and slow.

  double_illuminate might be a somewhat acceptable approximation in some
situations, assuming you are not seeing both sides at the same time (in
which case it would be very unrealistic).

-- 
                                                          - Warp

Post a reply to this message

Warp napsal(a):
> Jan Dvorak <jan### [at] centrumcz> wrote:
>>>   double_illuminate is not realistic. It doesn't correspond to any
>>> physical phenomenon.
>>>
>> It does correspond to any surface that is thin enough to be translucent 
>> but thick enough not to be transparent.
> 
>   No, it doesn't. Just take any material you want and compare its
> illumination on the side facing the light and on the opposite side.
> The illumination is totally different. With double_illuminate the
> illumination on both sides will be *identical*. This corresponds to
> nothing in nature.
> 
>   The only reason why double_illuminate exists in povray is because it's
> so laughably easy to implement (it's a 1-liner: 1 single 'if' statement;
> or more precisely, one additional condition in an existing 'if' statement),
> and it can be used in certain situations to eg. alleviate some rendering
> artifacts, as well as other purposes. It's not even intended to be a
> physically accurate feature.
> 
>> A good example is a paper 
> 
>   Emulating the illumination on the backside of a paper in a physically
> accurate way would be quite laborious and slow.
> 
>   double_illuminate might be a somewhat acceptable approximation in some
> situations, assuming you are not seeing both sides at the same time (in
> which case it would be very unrealistic).
> 
Read the "However, I do see a bit of unrealism" part.

Post a reply to this message