 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 20 Nov 2002 20:01:24 +0100
"Philippe Debar" <phd### [at] wanadoo be> wrote:
> Right now, I only use COLOR_FILTER and REF_WHITE to transform the
> sky's colors. I don't have any idea (yet) of how to integrate
> MAX_LUMEN. I guess I need to learn a bit more scientific knowledge.
Well, actually the MAX_LUMENS variable was a weird idea. I changed it
to a simple multiplier, now called EXPOSURE, as it was only a way to
control the overall level of light on the scene. I've also done some
minor changes and corrected some mistakes on the conversion algoritm,
but I've not announced the new version because I'm still muddling along
with some things (http://www.ignorancia.org/t_lightsys.php).
--
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...
> Well, actually the MAX_LUMENS variable was a weird idea. I changed it
> to a simple multiplier, now called EXPOSURE, as it was only a way to
> control the overall level of light on the scene.
>
> I've also done some
> minor changes and corrected some mistakes on the conversion algoritm,
Which one? (I do not have the files here to compare : they are on another
computer) Spectra -> rgb ?
I notice that Light_Color=lct2*lm*lm/MAX_LUMEN becomes Light_Color=
balanced_color *lm*EXPOSURE
I must confess I changed the squared lm to lm while I was trying your files,
but it was just because I could use the linear law more easily. Was the
squared lm physically wrong?
I also notice that the new balanced_color is a third of the old one. With
these two changes, I suppose the outputted color values are much lower. I
suppose one can use something like EXPOSURE = 3000/MAX_LUMEN as a rough
beginning value to get approximately the same results.
> but I've not announced the new version
Too late! Now it is done ;-)
Could I advise you to simplify your macro usage ? I would much more prefer
to write :
light_source {
<1,2,3>*1e6
Light_Color(cl_incandescent_60w, lm_w60_incandescent)
Cosine_Fallof_Spot()
point_at <9,8,7>
}
then the current long argument line that I find difficult to remember and
having to translate and rotate the light afterwards. BTW, wouldn't be good
to unify the cl/sp_sourcetype_##w and the lm_w##_sourcetype notation (I
prefer the former, but that's just personnal taste) ?
> because I'm still muddling along
> with some things (http://www.ignorancia.org/t_lightsys.php).
Many thanks !
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 20 Nov 2002 22:56:41 +0100
"Philippe Debar" <phd### [at] wanadoobe> wrote:
> Which one? (I do not have the files here to compare : they are on
> another computer) Spectra -> rgb ?
Both WavelengthToRGB() and SpectrumToRGB() have some bits corrected.
> I must confess I changed the squared lm to lm while I was trying your
> files, but it was just because I could use the linear law more easily.
> Was the squared lm physically wrong?
Well, lm*lm here had nothing to do with the square law (the relevant
part for that is fade_power and fade_distance). In fact the intensity
multiplier part was totally arbitrary.
> I also notice that the new balanced_color is a third of the old one.
> With these two changes, I suppose the outputted color values are much
> lower. I suppose one can use something like EXPOSURE = 3000/MAX_LUMEN
> as a rough beginning value to get approximately the same results.
I don't know... I simply use trial&error to get the light level I want
(this is one of the reasons for creating the macros, indeed).
> Could I advise you to simplify your macro usage ? I would much more
> prefer to write :
>
> light_source {
> <1,2,3>*1e6
> Light_Color(cl_incandescent_60w, lm_w60_incandescent)
> Cosine_Fallof_Spot()
> point_at <9,8,7>
> }
Wow! I haven't figured out this posibility, mainly because my main
concern at first was to avoid using light_source directly. But I must
admit that your suggestion is very fine, and of course permits much more
control without adding aditional parameters to the existing light()
macro. As it must be really easy, I will add these macros soon.
> BTW, wouldn't
> be good to unify the cl/sp_sourcetype_##w and the lm_w##_sourcetype
> notation (I prefer the former, but that's just personnal taste) ?
Er... hmmm... yes, I'm that inconsistent, sorry. I will unify all
the predefined variables too. Hopefully I'm going to have plenty of free
time from now to the end of the year, at least.
--
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
> Your suggestion is very fine, and of course permits much more
> control without adding aditional parameters to the existing light()
> macro. As it must be really easy, I will add these macros soon.
I just did them for my usage :
#macro Light_Color(lct,lm)
((vnormalize(lct/REF_WHITE)+(COLOR_FILTER.gray)-COLOR_FILTER)*lm*EXPOSURE)
#end
#macro Cosine_Falloff_Spot(Point_At)
spotlight radius -90 falloff 90 tightness 1 <0,-al,0> point_at Point_At
#end
> Er... hmmm... yes, I'm that inconsistent, sorry. I will unify all
> the predefined variables too. Hopefully I'm going to have plenty of free
> time from now to the end of the year, at least.
Many thanks.
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
*Philippe kicks himself vigorously*
#macro Cosine_Falloff_Spot(ala1, ala2, Point_At)
#local
al=sqrt(sqrt(((ala1.x+ala1.y+ala1.z)/3)*((ala2.x+ala2.y+ala2.z)/3)));
spotlight radius -90 falloff 90 tightness 1 point_at
vnormalize(Point_At)*al
#end
or
#macro Cosine_Falloff_Spot(al, Point_At)
spotlight radius -90 falloff 90 tightness 1 point_at
vnormalize(Point_At)*al
#end
I am not sure about al : it surely isn't the surface of the area and you
could have problem with square roots of negative numbers (you can fix that
with abs, but there are several different ways to do that and they would
produce quite different results, so...).
If you want the area, you could use :
#local
al=sqrt((pow(ala1.x,2)+pow(ala1.y,2)+pow(ala1.z,2))*(pow(ala2.x,2)+pow(ala2.
y,2)+pow(ala2.z,2));
but
#local al=vlength(ala1)*vlength(ala2);
is much easier and much more readable, and
#local al=vlength(vdot(ala1,ala2));
is even shorter and "more elegant" ;-)
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Philippe Debar wrote:
>See attached images (turbidity 1.0 and 8.0 skies)
>Sunrise is the same as sunset, except for the orientation (which isn't yet
>implemented)
Very nice!
A question, tho...
These 2 images are made with a 360 deg camera, right?
The white band near the horizon is expected?
I don't have the paper handy to check, so I wonder if it's an artifact of
the model or an artifact of the particular scene.
>I figured I would pass, as I believe it would require a patch (or a
>post-process).
>But I will surely try one day to reproduce it with media, loosing all the
>speed which was the model point.
Media can be slow, indeed...
>Soon, I promise. But right now it is still quickly mutating.
When-It's-Ready(tm) is an accepted and *much* appreciated release date.
Many thanks for the work,
Alex
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alex wrote:
> Very nice!
Thanks :-)
> A question, tho...
> These 2 images are made with a 360 deg camera, right?
Right... almost. It is a bit more than 360 to get a bit more space
between the spheres and the image's borders.
Here is the camera statement :
camera {
spherical
location <0,1.5,0>
look_at <0,1.5,1>
angle 360*7.25/7, 180
rotate (1+.4)*360/7*y
}
> The white band near the horizon is expected?
> I don't have the paper handy to check, so I wonder if it's an artifact of
> the model or an artifact of the particular scene.
I believe it is expected, that it is a feature of the model and not an
artifact. There are two parameters (x3 color components Yxy = 6
parameters) for tweaking that (brightening / darkening of the horizon
and gradient of the color at the horizon). However I still haven't tried
to modify Preetham's default settings.
The brightening is meant to simulate light scattering in the athmosphere
whithout using a scattering media which would be much more slower. The
downside : the sky and athmosphere must be homogenous.
>>Soon, I promise. But right now it is still quickly mutating.
>
>
> When-It's-Ready(tm) is an accepted and *much* appreciated release date.
;-)
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3dda84b5@news.povray.org Philippe Debar wrote:
> It is based on Preetham's model for skies found in "A practical
> analytical model for daylight".
> http://www.cs.utah.edu/vissim/papers/sunsky/index.html
>
reminded me of SkyPOV
http://www.geocities.com/SiliconValley/Program/9231/povray.html
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 20 Nov 2002 23:55:37 +0100
"Philippe Debar" <phd### [at] wanadoobe> wrote:
> I am not sure about al : it surely isn't the surface of the area
Yes, it's badly commented... it tries to be sqrt(sqrt(area)).
> you could have problem with square roots of negative numbers (you can
> fix that with abs, but there are several different ways to do that and
> they would produce quite different results, so...).
I do not expect negative numbers on area light vectors!
> #local al=vlength(ala1)*vlength(ala2);
Thanks! ...my maths are really poor.
> #local al=vlength(vdot(ala1,ala2));
Hmmm... sorry, as I said my maths are really bad: I can understand
the prior form (vlength*vlength), but this one scapes me, and gives
always 0. There is a typo?
--
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 Wed, 20 Nov 2002 23:55:37 +0100
> "Philippe Debar" <phd### [at] wanadoobe> wrote:
>
> > I am not sure about al : it surely isn't the surface of the area
>
> Yes, it's badly commented...
Well, it isn't released yet...
> it tries to be sqrt(sqrt(area)).
>
> > you could have problem with square roots of negative numbers (you can
> > fix that with abs, but there are several different ways to do that and
> > they would produce quite different results, so...).
>
> I do not expect negative numbers on area light vectors!
>
> > #local al=vlength(ala1)*vlength(ala2);
>
> Thanks! ...my maths are really poor.
>
> > #local al=vlength(vdot(ala1,ala2));
>
> Hmmm... sorry, as I said my maths are really bad: I can understand
> the prior form (vlength*vlength), but this one scapes me, and gives
> always 0. There is a typo?
Yes, there is a typo - in my head :-( I confused two functions. It should be
vcross instead of vdot. vdot gives a float and is null whenever the two
vectors are perpendicular, which is generally the case for area light
vectors... sorry. Vcross returns a vector which is perpendicular to the two
input vectors and whose length is the surface area of the parallelogram they
define.
To get sqrt(sqrt(area)), I'd use pow(vlength(vcross(ala1, ala2)),.25) -
hoping that it is right this time.
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
