I had a look at the scene and it looks like a good start.  However, It
doesn't use area lights like I thought you had said.  On another note, I
don't think it's necessary to use parallel lights, probably doesn't make
much of a difference though as long as your light dome is big enough.

I must say that I really like the texture on the sphere.  I've been meaning
to try something like that for a metallic paint finish for cars and stuff.

Keep up the good work.

-tgq

Post a reply to this message

The scene does use area lights, look:
   light_source {
    dir*1000, col*4/num_lights parallel point_at 0
    #if (area_ang > 0)
     area_light 
x*1000*tan(radians(area_ang)),y*1000*tan(radians(area_ang)),4,4 adaptive 1 
jitter circular orient
    #end
   }

That metallic paint was just a quick experiment that's turned out much 
better than I expected, I'm currently building a car model to show it off 
properly :-D

-- 
Tek
http://evilsuperbrain.com

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote in message 
news:web.461e4c64c3e2923bc150d4c10@news.povray.org...
>I had a look at the scene and it looks like a good start.  However, It
> doesn't use area lights like I thought you had said.  On another note, I
> don't think it's necessary to use parallel lights, probably doesn't make
> much of a difference though as long as your light dome is big enough.
>
> I must say that I really like the texture on the sphere.  I've been 
> meaning
> to try something like that for a metallic paint finish for cars and stuff.
>
> Keep up the good work.
>
> -tgq
>
>

Post a reply to this message

> 1) I started out with a full geodesic distribution and sampling.  Geodesic
> distribution has a slight downfall in that the spacing at the mid 
> latitudes
> (+- 45 deg)  is greater than at the poles and equator.

That's not really what I understand by the term "geodesic", I was thinking 
of using a geodisic distribution based on subdividing the triangles of an 
icosahedron like this 
http://en.wikipedia.org/wiki/Image:G%C3%A9ode_V_3_1.gif One light on each 
vertex would be a near perfect distribution.

-- 
Tek
http://evilsuperbrain.com

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote in message 
news:web.461e451cc3e2923bc150d4c10@news.povray.org...
> "Tek" <tek### [at] evilsuperbraincom> wrote:
>> My light dome's not adaptive like that. I sample each light from an 
>> average
>> of 20 points on the dome to get less aliasing, but for the light 
>> positions I
>> just messed with some formulae until I got a nice even distribution of
>> lights over the dome (I couldn't be bothered coding a geodisic dome light
>> placement). My formula for spreading lights over a sphere is:
>>
>>
>> To be honest I don't know why it gives such a good distribution, I found 
>> it
>> by trial and error, I have a knack for messing with pow() functions until 
>> I
>> get something that looks right!
>>
>> Your weighted sampling technique sounds good, I assume you use bigger 
>> area
>> lights if they're representing a region with less lights in (if you see 
>> what
>> I mean). My area lights are setup so I can specify an angular size for 
>> them,
>> which matches the region I'm sampling on the dome, the angular size was
>> chosen using a simple sun-dial test scene adjusted until the distinct
>> shadows overlapped enough that they looked like 1 smooth shadow.
>>
>
> My development process progressed as follows:
>
> 1) I started out with a full geodesic distribution and sampling.  Geodesic
> distribution has a slight downfall in that the spacing at the mid 
> latitudes
> (+- 45 deg)  is greater than at the poles and equator.
> 2) So then I switced to an equal spacing distribution. (basically divide 
> the
> circumference at the given height by the desired spacing and round to the
> nearest integer).
> Even distribution gave good results with a high number of lightsources 
> (2000
> or so) but was essentially oversampling in the low-light areas, needlessly
> adding more lights than required.
> 3) At this point I switched to a random point selection with 2 levels.
> Above a given brightness threshold, I chose a given number of light
> sources, and below the threshold another number of light sources.
> This allowed me to get more weighting to the bright lights, but I found I
> was now undersampling the low light too much (ie, not getting that blue
> ambient tinge in outdoor scenes).
> 4) Now I added centroidal voronoi tesselation techniques to gravitate the
> chosen point lights to a natural even brightness distribution.
> This was a little better, but was very computationally intensive.
> 5) At this point I came across median cut method and tried implementing
> this.  In order to do this efficiently, a few precalcs needed to be done.
> This involved prebuilding summed area tables for the HDR.  Because I had 
> to
> use a finite size to store the SATs, I had to choose a subdivision level 
> for
> the HDR (ie. pixelate it).
> This worked out quite well and was much more effective and quick at given 
> a
> nice equal brightness distribution with much fewer light sources (I use 
> 256
> typically).  One downfall is that at low subdivision (large pixel size)
> small point lights in the HDR could be lost.  This is remedied by
> increasing the subdivision (which adds to the parse time, but not render
> time)
> Along with the median cut method technique, I have the central voronoi
> tesselation technique still available to tweak the calculated distribution
> (though I never use it because of computation time).
>
> A few other features have been added along the way:
> 1) previewing of light distribution: renders a preview of the HDR itself
> showing the calculated light distribution.  Makes tweaking the numbers and
> seeing the results easy and quick to do.
> 2) Clipped area rebuilding algorithm:  artificially rebuilds clipped areas
> of HDRs (Some HDRs I have still have a cutoff threshold becuase of
> limitations in their creation).  This can also be used to try to adapt LDR
> images to the system, though the result may not be great and may need a 
> lot
> of tweaking of the variables.
> 3) Area lights: allows area lights to be used instead of point lights. 
> The
> size of the area light is determined by the size of the representative 
> area
> of the specific light source.
> 4) Automatic/manual brightness adjustment:  Allows the system to either
> automatically determine a good overall brightness of the lighting based on
> the brightness of the HDR or allow the user to target a given effective
> light brightness.
>
> And much more including a few experimental techniques/features like gamma
> adjustment and brightness weighting.
>
> It has turned out to be quite complex, but I am quite satisfied with the
> results I have been getting and feel that I am very near to being 
> satisfied
> enough to release it.
>
> The process also taught me a great deal about a number of items:
> -HDR images and concepts
> -programming methods
> -voronoi tesselations
> -median cut method
> -summed area tables
>
> I hope this helps you along the way with your progress. Whether what you 
> end
> up doing turns out to meet your expectations or not, you can still learn a
> lot about POV and other topics along the way.
>
> Feel free to ask more questions and I can try to answer or help if/when I
> can.
>
>
> -tgq
>
>

Post a reply to this message

"Tek" <tek### [at] evilsuperbraincom> wrote:
> The scene does use area lights, look:
>    light_source {
>     dir*1000, col*4/num_lights parallel point_at 0
>     #if (area_ang > 0)
>      area_light
> x*1000*tan(radians(area_ang)),y*1000*tan(radians(area_ang)),4,4 adaptive 1
> jitter circular orient
>     #end
>    }
>

You must've uploaded a different file:

light_source { dir*1000, col*4/num_lights parallel point_at 0 }

-tgq

Post a reply to this message

Doh! That's an older version of the file, the new one is posted as a reply 
to that in p.b.s-f

That also explains why you were talking about the metallic sphere (which is 
still in the new file, but commented out). I should have paid more 
attention!

-- 
Tek
http://evilsuperbrain.com

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote in message 
news:web.461e54f4c3e2923bc150d4c10@news.povray.org...
> "Tek" <tek### [at] evilsuperbraincom> wrote:
>> The scene does use area lights, look:
>>    light_source {
>>     dir*1000, col*4/num_lights parallel point_at 0
>>     #if (area_ang > 0)
>>      area_light
>> x*1000*tan(radians(area_ang)),y*1000*tan(radians(area_ang)),4,4 adaptive 
>> 1
>> jitter circular orient
>>     #end
>>    }
>>
>
> You must've uploaded a different file:
>
> light_source { dir*1000, col*4/num_lights parallel point_at 0 }
>
> -tgq
>
>

Post a reply to this message

Well, this is looking good. I finally got around to playing a bit
with HDR images and light domes, and I think a useful speed vs. quality
parameter would be a threshold for dropping light sources which do not
contribute a lot because the dome is locally dark.

Here's an adapted version of your do_lights macro, although I don't
have the patience to do such high quality renders and not the eye
for detecting the subtle differences in the shadows. Maybe you want
to try it out. It simply skips light sources when the value is below
a specified threshold, but sneakily preserves the global illumination
by distributing the lost light over the remaining light sources.

For this, light source creation had to be delayed into a second phase.
I also dropped "parallel" and "point_at" because I had strange effects
with that and the dome should simulate diffuse lighting anyway? BTW,
I never used point_at without spot_light, is it implicit?

Of course, a *really* smart macro might perform a recursive subdivision
on the sphere, using more light sources in areas where there is a lot of
light and/or structure, similar to anti-aliasing ;)

Post a reply to this message

Attachments:
Download 'us-ascii' (3 KB)

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Of course, a *really* smart macro might perform a recursive subdivision
> on the sphere, using more light sources in areas where there is a lot of
> light and/or structure, similar to anti-aliasing ;)

Perhaps I should think about releasing the one that I have been developing
for a while (perhaps this week, I think I am probably at a point where I am
satisfied with its performance...).  It sort of does what your are
describing through use of a median cut algorithm which does it naturally
without the need for recursion.  It is basically the opposite of the idea
of evenly placing light sources with varying brightness.  It instead places
light sources of equal brightness with varying spacing.  With this method, a
good overall scene lighting is achieved with fewer light sources and without
sacrificing light contribution from any one area.

-tgq

Post a reply to this message

Oops, accidentally posted broken version, replace

   #local skipped_col_cumul = skipped_col_cumul + col;

with

   #local skipped_light_cumul = skipped_light_cumul + col;

Post a reply to this message

Okay,
It's been plaguing me.... what is HDR and what program uses HDR?

Post a reply to this message

"Allen" <nomail@nomail> wrote:
> Okay,
> It's been plaguing me.... what is HDR and what program uses HDR?

From a response I gave previously on this:
(http://news.povray.org/povray.advanced-users/message/%3Cweb.44eef0ad8da26955c150d4c10%40news.povray.org%3E/#%3Cweb.44e
ef0ad8da26955c150d4c10%40news.povray.org%3E)

"When most image types are written/displayed, the coulour values range from
0
to 1. However, in real life, light brightness is by no means limited to 1
(i.e., compare the sun to a light bulb to a white piece of paper), in fact
it can be substantially more, relatively speaking.  So when photos (or
equally, rendered images are written, the colour of superbright objects get
clipped at 1 because of the image file limitations and the true brightness
of the scene gets lost.  This is generally fine for an image meant for
direct viewing, however, if we want to use the image for something where
the brightness is required (e.g. reflection maps, environment lighting,
or,as you want to do, scene lighting evaluation) then we end up getting
false results, because the true brightness of the +1 pixels is lost and
they are treated the same as pixels with an actual value of 1 (i.e., in the
image sun, the light bulb and the white piece of paper will all be treated
as having the same brightness even though this is clearly untrue).  HDR
(called high-dynamic range as opposed to LDR or low-dynamic range) and some
other format save pixel values as floating point numbers and can save the
actual value of each pixel,no matter what the value, thus preserving the
true brightness or dynamic range of the image. Unfortuneatley POVRay 3.6
does not support HDR (it is being implemented in the 3.7 beta however) but
megaPOV does (http://megapov.inetart.net/).

I hope this has been more helpful than confusing.  If you have any more
questions or want to see some examples of how it can work, feel free to
ask.  Also,have a look at this page, as it has some good information and
illustrations of HDR vs LDR:
http://www.highpoly3d.com/writer/tutorials/hdri/hdri.htm"

Further:
HDR is just an image file format, it just contains additional information
(ie, brightness exponent) compared to jpg, bmp, etc.  So any program that
can read images could be modified to read and use HDR images (as the
current both megaPOV and the POV 3.7 betas have).  There is a lot of
information and resources on this topic if you want to search more.

-tgq

Post a reply to this message