 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Skylight.inc is an include file for POV-Ray 3.5 for creating realistic
skies.
It implements in povray SDL the sky model Preetham describes in "A practical
analytical model for daylight"
(http://www.cs.utah.edu/vissim/papers/sunsky/index.html).
Features (in no particular order):
* Main sky parameters: solar altitude and sky turbidity;
* Some additional parameters: north, solar azimuth, turbulence;
* "Smart" (er...) global luminosity control;
* Turbulence;
* Compatible with and improves sunpos.inc (adds north);
* Compatible with Jaime Vives Piqueres' excellent lighting macros;
* Quick hack to correct Preetham's model under the horizon;
* Quick to trace: uses a mesh;
* Most, if not all, features are easy to override;
* Overall_Filter macro to change the outputted colours the way you want;
* Outputs sun colour to light your scenes coherently with your skies;
* Easy to use: you can just include the file and get a default sky or set
any combination of parameters you want;
* I tried to keep the code legible and well commented.
Tessellation features:
* Minimum and maximum tessellation controls;
* Adaptive tessellation using CMC(1:1) colour difference formula;
* Information if tessellation isn't complete.
Bonus:
* Macros to convert from RGB to CIE XYZ and Yxy colour spaces and back;
* CMC(1:1) colour difference macro.
In next releases, probably:
* Better identifiers names, cleaner implementation;
* Tools to easily adapt the models default values to your needs (change
colours, saturate, change sun corona, change horizon sky behaviour, ...);
* Documentation and example scenes, including reasonable parameters range;
* Save the sky dome mesh to an include file (should save parsing time);
* Better (and maybe quicker) tessellation;
* Ability to remove bottom slice of the dome to save needless work and data;
* Overcast parameter;
* Better integration with Jaime Vives Piqueres lighting macros and smarter
luminosity control - I will try to find and use realistic luminosities for
sky and sun.
Later, maybe:
* Atmospheric media settings;
* Clouds.
Known problems/bugs:
* Black dots sometimes show in the sky. I believe this happens whenever a
ray is shot "between" two triangles. Up to now, anti-alias always got rid of
this annoyance.
* Tessellation isn't optimised: it uses more vertices and faces than it
could (hence the uses / has #debug messages) and wastes some computations.
However I am not sure it is worth optimising.
* Integration with Jaime's lightsys isn't complete : MAX_LUMEN / EXPOSURE
have no effects yet, as I do not now how to convert CIE trichromacity values
to lumens.
In the meantime, I hope you will enjoy this file and find it useful. I
really am impatient to read your comments, criticisms and suggestions. And
to see your images.
Povingly,
Philippe
phd### [at] yahoo fr
===============
DOCUMENTATION
===============
In the following text, default values are noted [like this].
Warning: this is still a beta, do not expect any backward compatibility
with next releases.
== How to use ==
As all settings have default values, you can simply use :
#include "skylight.inc"
Else, you #declare any setting you want to override before including the
file.
== Sky dome geometry ==
DomeSize [1e5]
The radius of the generated dome (this is the distance between a vertex and
the origin <0,0,0>, face centres are nearer).
North [-z]
An horizontal vector (North.y=0) that gives the orientation of the scene.
Al[35]
Az[45]
Altitude and azimuth of the sun in degrees. These parameters can be computed
using sunpos.inc (standard POV_Ray 3.5 distribution).
UseSolarPosition [undefined]
SolarPosition [computed from Al and Az]
Al and Az are used by default to build the skydome. If you want to use
SolarPosition, you have to #declare UseSolarPosition=true; and #declare a
position vector for SolarPosition.
== Atmospheric parameters ==
Current_Turbidity [3]
The sky turbidity. Low values give a clear blue sky, higher values
a dustier, redder one. I found that good values are from 2 to 8.
Not that this does not produce clouds, mist and that there is
currently no way short of tempering with ABCDE parameters (see
inside Skylight.inc to find them) to produce an overcast sky.
== Luminosity ==
Intensity_Mult [.75]
Int_Sun_weight [2]
Int_Zenith_weight [1]
Int_Horizon_weight [1]
I tried to implement a kind of smart luminosity adjustment. Skylight
multiply the model's luminosity (Y) values to get Intensity_Mult at a target
value, which is a weighted mean of the luminosity of the sky at the sun's
position, at the zenith and on the horizon opposite to the sun. Adjust
Intensity_Mult to change the overall sky luminosity.
== Jaime Vives Piqueres' excellent lighting macros ==
Include them before Skylight.inc and the sky dome is automatically colour
adjusted and filtered. Luminosity interaction is really basic and you will
need to tweak Intensity_Mult.
== Overall light filter ==
Overall_Filter(lct) is a macro that does nothing that wraps the color
generation code before Jaime Vives Piqueres' macro are applied. You can
override it to change colors the way you like. Beware that too strong
transformations can make artefacts visible.
== Tesselation ==
Tesselation_Trigger [.95]
A float controlling the adaptive tessellation through the CMC(1:1) colour
difference formula. Use lower values if you need to eliminate visible
tessellation artefacts (I think these should not happen with the default
value), higher values to get a quicker parsing but dirtier result (although
it can be pleasant). Be aware that you may have to raise Max_Vertices to
allow tessellation to proceed up to your chosen Tesselation_Trigger.
Max_Vertices [5000]
Controls the maximum number of vertices generated (which is not the number
of vertices used, as there are many duplicates). Lower values lead to
dirtier but quicker results ; higher ones give the possibility to more
tessellation. Augment Max_Vertices if you get a "Warning: Tesselation ended
while tesselation wasn't complete : maximum number of vertices is met."
Message and want to get more details.
Min_Vertices [72]
Controls the minimum number of vertices generated. Tesselation is forced
while the number of generated vertices is under this trigger. Values of 12
or less have no effects. The default value forces one complete tessellation
of the base icosahedron.
Max_Faces [20+4/3*(Max_Vertices-12)+1]
Controls the maximum number of faces generated. You should use Max_Vertices
instead.
== Turbulence ==
Turb_amount [undefined]
Turb_param [<2.0, 0.5, 6>]; //<lambda, omega, octaves>
Turb_scale [5]
Define Turb_amount to get some turbulence in the sky. Be prepared to ramp
Max_Vertices up.
== Outputs ==
Skylight.inc outputs (#declares) the following identifiers :
SolarPosition : the sun's position vector (on the dome).
SunColor : the sun's colour (really the sky's colour at sun's position).
Skylight.inc may change some declared values (eg : SolarPosition, North)
Post a reply to this message
Attachments:
Download 'Skylight06b.zip' (15 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Philippe Debar wrote:
>Skylight.inc is an include file for POV-Ray 3.5 for creating realistic
>skies.
>It implements in povray SDL the sky model Preetham describes in "A practical
>analytical model for daylight"
>(http://www://www.cs.utah.edu/vissim/papers/sunsky/index.html.
You've beaten me by at least two months!
Now to get to work with the files ...
Results soon
John
--
Run Fast
Run Free
Run Linux
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks Philippe
--
Martial
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Martial" <mar### [at] pov-mondeorg> wrote
> Thanks Philippe
:-D
My pleasure, really.
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
