> 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