POV-Ray : Newsgroups : povray.binaries.scene-files : Skylight include file Server Time
2 Sep 2024 08:16:54 EDT (-0400)
  Skylight include file (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: Philippe Debar
Subject: Re: Skylight include file
Date: 7 Dec 2002 13:30:25
Message: <3df23e41@news.povray.org>
"Martial" <mar### [at] pov-mondeorg> wrote
> Thanks Philippe

:-D

My pleasure, really.



Philippe


Post a reply to this message

From: Philippe Debar
Subject: Known bug and workaround
Date: 7 Dec 2002 13:52:24
Message: <3df24368$1@news.povray.org>
You will get very visible artifacts if you define a #default texture with
finish items before including Skylight.inc. Two workarounds:
1) define you default texture after including Skylight.inc
2) adapt fiLuminous declaration in Skylight.inc  (line 84) to counteract
your #default (eg specify specular 0 phong 0 reflection 0, ...)

The problem is probably much the same with #default normal items (although
I'd say these must be rarer).

This will be fixed for next release.

Povingly,


Philippe


Post a reply to this message

From: Philippe Debar
Subject: Lighting system blunders
Date: 10 Dec 2002 04:58:19
Message: <3DF5BA2E.3050902@wanadoo.be>
OK

I made several mistakes with the integration of Jaime Vives Piqueres'
lighting system in Skylight.inc.

Firstly, demo files D and E which should have shown how smoothly the two
include files work together (in my dreams) do not run. That is because I
used a beta-version of Jaime's lighting system and the file structure is
different from the released one. Drats. However, Skylight should work
correctly with correct lightsys I and II, even if demos D and E do not
work. Just set lightsys parameters (REF_WHITE, COLOR_FILTER and
MAX_LUMEN / EXPOSURE) before including Skylight.inc. And it should work
correctly, except that...

I think I made a grevious mistake while adapting Jaime's code. 
Luminosity interaction is supposed not to be perfect. I think I should 
make the following adaptations :
line 315 : vlength(lct) -> lct.gray
line 327 : sqrt(vlength(lct)) -> lct.gray
A word of warning: this code is totally untested (I do not have Pov here).


Povingly,


Philippe


Post a reply to this message

From: Jaime Vives Piqueres
Subject: Re: Lighting system blunders
Date: 10 Dec 2002 06:46:56
Message: <20021210124654.773beda6.jaimevives@ignorancia.org>
On Tue, 10 Dec 2002 10:55:58 +0100
Philippe Debar <phd### [at] wanadoobe> wrote:

> I made several mistakes...

  Not really difficult if my code is involved...
 
> Firstly, demo files D and E which should have shown how smoothly the
> two include files work together (in my dreams) do not run. That is
> because I used a beta-version of Jaime's lighting system and the file
> structure is different from the released one. Drats. 

  I haven't noticed it because I have not traced the demos...:) Sorry,
but I was just starting an outdoor scenes, I used Skylight for first
time on it, rather than first trying the demos.

> I think I made a grevious mistake while adapting Jaime's code. 
> Luminosity interaction is supposed not to be perfect. I think I should
> make the following adaptations :
> line 315 : vlength(lct) -> lct.gray
> line 327 : sqrt(vlength(lct)) -> lct.gray

  Well, I've tested this part and I've done my own modifications. It
even helped to find some faulty asumptions I was doing with the color
filter operations. Apart from this, I think you must not use at all
anyhting in the place of lm, and let the intensity control of the sun
to Skylight only. Just like this:

(((lct/REF_WHITE)+(<COLOR_FILTER.gray,COLOR_FILTER.gray,COLOR_FILTER.gr
ay>-COLOR_FILTER))*EXPOSURE) 

  This way, if I set EXPOSURE to 1, REF_WHITE to <1,1,1> and
COLOR_FILTER to <0,0,0>, the the resulting image is the same as if these
variables where not declared, whih is the correct behavior, I think. It
also works fine with the incoming version III, indeed.

  And one more thing, you can forget about compatibility with version
I, as it was just a mess.

  For the rest of the Skylight include, I must say that I'm really
impresed. I have not tried even to understand the code, but I see it is
very nicely done and the results seem almost perfect in terms of
colors. Only two things annoy me:

  1) The skydome texture is based on a luminous finish, with ambient,
wich is perhaps not handy for lazy people like me, wich uses global
ambient set to 0. I just have modified my copy to use "diffuse 1" and
it works great.

  2) Both with low and high tesselation, I see on the skydome
different "poligonal" zones, showing slighty different colors, but I
can't figure what is causing it. Will test it further, as I'm taking the
rest of the day free... :)

  Again: great work, Phillipe! 


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org


Post a reply to this message

From: Philippe Debar
Subject: Re: Lighting system blunders
Date: 10 Dec 2002 15:37:20
Message: <3df65080@news.povray.org>
"Jaime Vives Piqueres" <jai### [at] ignoranciaorg> wrote in message
news:200### [at] ignoranciaorg...

> On Tue, 10 Dec 2002 10:55:58 +0100
> Philippe Debar <phd### [at] wanadoobe> wrote:
>
> > I made several mistakes...
>
>   Not really difficult if my code is involved...



You won't take away from the glory of my mistakes! They were my own! My own!
;-) ;-) ;-)

(More seriously: they were.)



> > Firstly, demo files D and E which should have shown how smoothly the
> > two include files work together (in my dreams) do not run. That is
> > because I used a beta-version of Jaime's lighting system and the file
> > structure is different from the released one. Drats.
>
>   I haven't noticed it because I have not traced the demos...:) Sorry,
> but I was just starting an outdoor scenes, I used Skylight for first
> time on it, rather than first trying the demos.



No problem. I usually act the same (then understand that I do not
understand, and then run and study the demos ;-)).





>   Well, I've tested this part and I've done my own modifications. It
> even helped to find some faulty asumptions I was doing with the color
> filter operations. Apart from this, I think you must not use at all
> anyhting in the place of lm, and let the intensity control of the sun
> to Skylight only.



You mean: I should not adjust the luminosity of the sky with your code, but
leave it wholly independent? I plan to have one day a "scientific" Y to
lumen conversion and hence have a real integration with your system. In the
meanwhile, I wanted the luminosity to be dependant both on Intensity_Mult
and on Exposure.



> Just like this:
>
> (((lct/REF_WHITE)+(<COLOR_FILTER.gray,COLOR_FILTER.gray,COLOR_FILTER.gr
> ay>-COLOR_FILTER))*EXPOSURE)
>
>   This way, if I set EXPOSURE to 1, REF_WHITE to <1,1,1> and
> COLOR_FILTER to <0,0,0>, the the resulting image is the same as if these
> variables where not declared, whih is the correct behavior, I think. It
> also works fine with the incoming version III, indeed.



It looks very logical. I'll think about it. If anybody test this, I'll be
happy to hear their thoughts.





>   And one more thing, you can forget about compatibility with version
> I, as it was just a mess.



I'll think about removing it. But I wanted to offer as much compatibility as
I could.





>   For the rest of the Skylight include, I must say that I'm really
> impresed. I have not tried even to understand the code,



It's not that complicated, really. It looks like it is, but it really is
mathematical formulas copied from the paper into SDL.



> but I see it is
> very nicely done and the results seem almost perfect in terms of
> colors.



Many thanks. But once again: the merit is Preetham's.




> Only two things annoy me:
>
>   1) The skydome texture is based on a luminous finish, with ambient,
> wich is perhaps not handy for lazy people like me, wich uses global
> ambient set to 0. I just have modified my copy to use "diffuse 1" and
> it works great.



Yes, it is because I designed it to use with radiosity, to get realistic
lighting.



Furthermore, with diffuse 0 ambient 1 (and no highlights) it looks the same
whatever the light sources in the scene are, which was my goal. With diffuse
1 (and I suppose ambient 0), it is dependant on the scene lighting. I did
not test it that way, so I had no idea the results would be good, but I am
really happy to learn it :-)



BTW, I forgot to include fiLuminous in #ifndef(...#end. That would have
allowed you to do the same without modifying the include file.


>   2) Both with low and high tesselation, I see on the skydome
> different "poligonal" zones, showing slighty different colors, but I
> can't figure what is causing it.



I bet it is diffuse 1, which makes the sky colors dependant on the lighting,
so the difference in orientation of the polygons shows. For the time being I
can think of no solution but leaving diffuse 0 and ambient 1 and play with
Intensity_Mult to get the luminosity you seek. I may try to add normals to
the mesh to reduce this problem.



> Will test it further, as I'm taking the
> rest of the day free... :)



Lucky you ;-) Enjoy your day off!





>   Again: great work, Phillipe!



Many thanks!





Povingly,





Philippe


Post a reply to this message

From: Jaime Vives Piqueres
Subject: Re: Lighting system blunders
Date: 11 Dec 2002 08:59:49
Message: <20021211145948.386cb886.jaimevives@ignorancia.org>
On Tue, 10 Dec 2002 21:38:07 +0100
"Philippe Debar" <phd### [at] wanadoobe> wrote:

> You mean: I should not adjust the luminosity of the sky with your
> code, but leave it wholly independent? I plan to have one day a
> "scientific" Y to lumen conversion and hence have a real integration
> with your system. In the meanwhile, I wanted the luminosity to be
> dependant both on Intensity_Mult and on Exposure.

  No, I mean to not involve here the Lumens value. The overall scene
luminosity can still be controlled with EXPOSURE, and the sun/sky
intensity (lumens) with Intensity_Mult. That is, I can setup Skylight
ith Intensity_Mult to have an intensity proportionally correct respect
to the other lightsys lights, changing the overall luminosity of both
at once with EXPOSURE. 

 If you come up with a way to convert Y to Lumens, that would be
aditionally nice, because sun/sky intensity will be automatically
proportional to the lightsys lights (if you feed them with realistic
lumens values, of course).

> > (((lct/REF_WHITE)+(<COLOR_FILTER.gray,COLOR_FILTER.gray,COLOR_FILTE
> > R.gr ay>-COLOR_FILTER))*EXPOSURE)
>
> It looks very logical. I'll think about it. If anybody test this, I'll
> be happy to hear their thoughts.

  At least, the change to the "gray vector" on the color filter seems
necesary to get proper results: I changed it too for the next version of
my light macros (I've not tested it, but I'm supossing it was a bad
assumption for my part on float to vector promotion, or something...).

> It's not that complicated, really. It looks like it is, but it really
> is mathematical formulas copied from the paper into SDL.

  That is exactly what I was refering to: these papers are usually for
people who understand maths. 
 
> Many thanks. But once again: the merit is Preetham's.

  Yes, but you have the merit of being good enough, both at the SDL and
color maths, to port such "crude" scientific papers.
 
> >   1) The skydome texture is based on a luminous finish, with
> 
> Yes, it is because I designed it to use with radiosity, to get
> realistic lighting.
> 
> Furthermore, with diffuse 0 ambient 1 (and no highlights) it looks the
> same whatever the light sources in the scene are, which was my goal.
> With diffuse 1 (and I suppose ambient 0), it is dependant on the scene
> lighting. I did not test it that way, so I had no idea the results
> would be good, but I am really happy to learn it :-)

 Hmmm... I suppose you're saying that you don't want ths sky being
lighted with radiosity? Yes, that seems logical, as it changes the
exact colors calculated by Skylight, and the model is then not accurate.

 But, on the other hand, the POV docs encourage to use global ambient
set to 0 for radiosity with light sources, wich is what I do usually, to
use predefined and existant textures wich have ambient (rather than
changing all the textures to set ambient to 0). What's the solution in
that case? I can't think of anything right now... 

> I bet it is diffuse 1, which makes the sky colors dependant on the
> lighting, so the difference in orientation of the polygons shows.

  You're right! And don't worry: "brilliance 0" solves partially the
problem.:) Still, it's not the correct method to use your include,
because the sky gets excesively bright. I suppose it can be solved
decreasing the overall luminosity and decreasing the weight of the
sun... will try this too. 

  Next time I will post a first WIP for the scene where I'm using
Skylight.inc... regards.


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org


Post a reply to this message

From: Philippe Debar
Subject: Re: Lighting system blunders
Date: 11 Dec 2002 12:53:51
Message: <3df77baf$1@news.povray.org>
"Jaime Vives Piqueres" <jai### [at] ignoranciaorg> wrote in message
news:200### [at] ignoranciaorg...

>   No, I mean to not involve here the Lumens value.



Okay. But if I read the formula right, it is still implicitly present, as
lct/REF_WHITE is no more normalized. It should be more or less equivalent.



BTW I have some colour theory ideas for lightsys, but I need to test them
first. If I believe them to be of any interest, I'll mail them to you.





> The overall scene
> luminosity can still be controlled with EXPOSURE, and the sun/sky
> intensity (lumens) with Intensity_Mult. That is, I can setup Skylight
> ith Intensity_Mult to have an intensity proportionally correct respect
> to the other lightsys lights, changing the overall luminosity of both
> at once with EXPOSURE.
>
>  If you come up with a way to convert Y to Lumens, that would be
> aditionally nice, because sun/sky intensity will be automatically
> proportional to the lightsys lights (if you feed them with realistic
> lumens values, of course).



That was my goal from the start ;-)





> > It's not that complicated, really. It looks like it is, but it really
> > is mathematical formulas copied from the paper into SDL.
>
>   That is exactly what I was refering to: these papers are usually for
> people who understand maths.



I just ignored the parts I did not understand ;-)



<snip>

>  Hmmm... I suppose you're saying that you don't want ths sky being
> lighted with radiosity? Yes, that seems logical, as it changes the
> exact colors calculated by Skylight, and the model is then not accurate.



Yes and no. I do not want the sky to be lighted by anything but itself.
Moreover, I want the sky to act as a light_source for radiosity, hence the
high ambient value and higher then <1,1,1> colours as you go near the sun.





>  But, on the other hand, the POV docs encourage to use global ambient
> set to 0 for radiosity with light sources, wich is what I do usually, to
> use predefined and existant textures wich have ambient (rather than
> changing all the textures to set ambient to 0).



Yes, POV says to use ambient 0 in radiosity for non-light-emitting objects.
But I want the sky to be luminous, that is to light objects in the scene. It
is no only a pretty / accurate (?) background, it also provides a realistic
(? again) outdoor light setup.





> What's the solution in
> that case? I can't think of anything right now...



What are the problems with the way it originally is? Tell me what isn't to
your taste, I'll try to solve it.





> > I bet it is diffuse 1, which makes the sky colors dependant on the
> > lighting, so the difference in orientation of the polygons shows.
>
>   You're right! And don't worry: "brilliance 0" solves partially the
> problem.:) Still, it's not the correct method to use your include,
> because the sky gets excesively bright. I suppose it can be solved
> decreasing the overall luminosity and decreasing the weight of the
> sun... will try this too.



Decreasing the weight of the sun will probably increase the sky luminosity.




>   Next time I will post a first WIP for the scene where I'm using
> Skylight.inc... regards.





I am awaiting your image impatiently.



I hope you will not have to struggle too much with my file ;-)





Povingly,





Philippe


Post a reply to this message

From: Jaime Vives Piqueres
Subject: Re: Lighting system blunders
Date: 11 Dec 2002 15:05:00
Message: <20021211210500.69316ac9.jaimevives@ignorancia.org>
On Wed, 11 Dec 2002 18:54:41 +0100
"Philippe Debar" <phd### [at] wanadoobe> wrote:

> Okay. But if I read the formula right, it is still implicitly present,
> as lct/REF_WHITE is no more normalized. It should be more or less
> equivalent.

  Oops! I forget it, sorry:

(vnormalize((lct/REF_WHITE)+(<COLOR_FILTER.gray,COLOR_FILTER.gray,COLOR
_FILTER.gray>-COLOR_FILTER))*EXPOSURE) 

  Then no local intensity involved now... only the temperature
correction and color balancing, and of course the global exposure.

> BTW I have some colour theory ideas for lightsys, but I need to test
> them first. If I believe them to be of any interest, I'll mail them to
> you.

  Please! I only barely understand what I'm doing... any help, specially
on color theory, will be very welcomed.

> I just ignored the parts I did not understand ;-)

  Ah! This is an ancient technique... I use it so often that I even
honoured it with the name of my web site. :)
 
> Yes and no. I do not want the sky to be lighted by anything but
> itself. Moreover, I want the sky to act as a light_source for
> radiosity, hence the high ambient value and higher then <1,1,1>
> colours as you go near the sun.
> [...]
> Yes, POV says to use ambient 0 in radiosity for non-light-emitting
> objects. But I want the sky to be luminous, that is to light objects
> in the scene. It is no only a pretty / accurate (?) background, it
> also provides a realistic(? again) outdoor light setup.

  That's what I supposed. Anyhow, the SunColor returned isn't
supposed to have the sky color weighted in it? 

> What are the problems with the way it originally is? Tell me what
> isn't to your taste, I'll try to solve it.

  Perhaps I've not explained it very well: How I can use it on my
scenes, having this dirty (and perhaps stupid) habit of using global
ambient set to 0? 

> Decreasing the weight of the sun will probably increase the sky
> luminosity.

  Sorry, I wanted to write "decreasing overall luminosity and increasing
sun weight", of course... I must pay more attention to what I write. :(

> I hope you will not have to struggle too much with my file ;-)

  Not really... only with the fiLuminous declaration, really. 

  Well, going back to skylighting... 

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org


Post a reply to this message

From: Philippe Debar
Subject: Re: Lighting system blunders
Date: 11 Dec 2002 18:17:44
Message: <3df7c798@news.povray.org>
"Jaime Vives Piqueres" <jai### [at] ignoranciaorg> wrote in message
news:200### [at] ignoranciaorg...

> (vnormalize((lct/REF_WHITE)+(<COLOR_FILTER.gray,COLOR_FILTER.gray,COLOR
> _FILTER.gray>-COLOR_FILTER))*EXPOSURE)
>
>   Then no local intensity involved now... only the temperature
> correction and color balancing, and of course the global exposure.



I think that if I do that, Intensity_Mult will have no effects any more, so
you would be unable to set the sky luminosty relatively to the rest of the
scene.

I use Lct.gray, Lct beeing the color generated by the sky model, as lumen to
get an final light intensity related to the original intensity and allow
Intensity_Mult to affect it. With the formula you propose, all
lights/colours will be normalized, every point on the sky will be of equal
'brightness' (in the r+g+b sense, not in perceptual luminance).



<snip>

> > I just ignored the parts I did not understand ;-)
>
>   Ah! This is an ancient technique... I use it so often that I even
> honoured it with the name of my web site. :)



And a nice name it is, too. I  like it.





> > Yes and no. I do not want the sky to be lighted by anything but
> > itself. Moreover, I want the sky to act as a light_source for
> > radiosity, hence the high ambient value and higher then <1,1,1>
> > colours as you go near the sun.
> > [...]
> > Yes, POV says to use ambient 0 in radiosity for non-light-emitting
> > objects. But I want the sky to be luminous, that is to light objects
> > in the scene. It is no only a pretty / accurate (?) background, it
> > also provides a realistic(? again) outdoor light setup.
>
>   That's what I supposed. Anyhow, the SunColor returned isn't
> supposed to have the sky color weighted in it?



SunColor is the color of the sky (given by the model) at SolarPosition. I
found that using a light_source {SolarPosition SunColor} led to nicer
images.





> > What are the problems with the way it originally is? Tell me what
> > isn't to your taste, I'll try to solve it.
>
>   Perhaps I've not explained it very well: How I can use it on my
> scenes, having this dirty (and perhaps stupid) habit of using global
> ambient set to 0?



Sorry, I read too quickly and misunderstood. I set #default{finish{ambient
0}}, which has exactly the same effect, unless a texture specify an ambient.
This wont work if you use global ambient to override a non-zero ambient
specified in a texture. But it shouldn't be much work to replace any ambient
float to ambient 0 or comment it.



BTW, the complete #default I most usually use is #default{pigment{rgb
.66}finish{ambient (fRad?0:.2)}}, fRad being a flag I use for switching
radiosity. That way it look nice (er... kind of) with or without radiosity.
Alternatively I set ambient 0 and add a secondary light_source opposite to
the first and less intense in a #if(fRad)...#end structure.





>   Well, going back to skylighting...



:-D





Povingly,





Philippe


Post a reply to this message

From: Xplo Eristotle
Subject: Re: Lighting system blunders
Date: 14 Dec 2002 18:55:05
Message: <3dfbc4d9@news.povray.org>
Jaime Vives Piqueres wrote:
>  But, on the other hand, the POV docs encourage to use global ambient
> set to 0 for radiosity with light sources, wich is what I do usually, to
> use predefined and existant textures wich have ambient (rather than
> changing all the textures to set ambient to 0). What's the solution in
> that case? I can't think of anything right now... 

I think the solution is to stop making and using textures that have 
ambient in them but shouldn't.

-Xplo


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.