 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I decided to have a play with HDR. I was getting really really *really* ugly
lighting using radiosity (even with very high quality settings) so this
image was created using Megapov's no_radiosity flag on the sky dome, and 110
area lights sampled from the dome to get the lighting. I did some tests and
110 lights with the right amount of blur looked pretty much identical to
5000 non-area lights.
I chucked a glowing orb in there so you can see it's still doing radiosity,
it's just the light from the HDR image is done using lightsources not
radiosity.
HDR probe is from the website of a friend of mine: http://unparent.com/
(photography->hdr probes)
Comments appreciated, I'm trying to get it to look pretty realistic. I'll
post the source if anyone wants it.
--
Tek
http://evilsuperbrain.com
Post a reply to this message
Attachments:
Download 'hdr-megapov-1.21.jpg' (156 KB)
Preview of image 'hdr-megapov-1.21.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I like it, although I think you are being let down by the HDR probe you are
using: generally it looks a little wavy, and it is particularly noticeable
on the white trim of the house around the doorway.
Perhaps you could turn that into a feature by adding some mist/steam rising
from the water to imply that is the cause of the wavy effect?
Having said that I like your approach to HDR lighting and I wouldn't mind
having a look at the source.
Cheers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well if it were a finished picture I'd make sure the HDR probe was either
not visible (except in reflections) or was very out of focus.
--
Tek
http://evilsuperbrain.com
"scam" <sca### [at] mail usydeduau> wrote in message
news:web.461c68e6c3e2923b5ffa356d0@news.povray.org...
>I like it, although I think you are being let down by the HDR probe you are
> using: generally it looks a little wavy, and it is particularly noticeable
> on the white trim of the house around the doorway.
>
> Perhaps you could turn that into a feature by adding some mist/steam
> rising
> from the water to imply that is the cause of the wavy effect?
>
> Having said that I like your approach to HDR lighting and I wouldn't mind
> having a look at the source.
>
> Cheers.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
First, thanks to the link to the HDRs, more to add to my collection! (you
can never hav enough in my opinion...)
Second, looks pretty good. Are you using any kind of weighted sampling? A
good weighting technique can reduce the number of lights needed to get good
results. I have been working on a lightdome macro that creates environment
lighting from HDRs for quite some time now (not quite made it public, a few
more tweaks maybe). Within the last month or so of development, I added
area light support and found it worked out quite nicely. With point
lights, I was using about 256 (2^8) light sources with pretty good results,
but still had some artifacting visible depending on the probe used. With
area lights, I found I could get similar results, but with less artifacting
with as little as 32 (2^5) 3x3 area lights.
I would like to see your scene perhaps to see how my lighting macro
performs.
If you need any further information on this, I'll see what I can do (I've
been quite busy at non-POV lately, so have been here less frequently
recently).
I still hope to release my lighting macro at some point, I just have to
convince myself that I'm satisfied with its operation.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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:
#declare invpow = function(x,p) {
select(x,-1+pow(1-abs(x),p),1-pow(1-abs(x),p)) }
#while (i < num_lights)
#local j=(i+.5)/num_lights;
#local dir =
vrotate(z,<invpow(j*2-1,.5)*90,invpow(j*2-1,.5)*sqrt(num_lights)*180,0>);
...place light...
#local i=i+1;
#end
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.
--
Tek
http://evilsuperbrain.com
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote in message
news:web.461d485ac3e2923bc150d4c10@news.povray.org...
> First, thanks to the link to the HDRs, more to add to my collection! (you
> can never hav enough in my opinion...)
>
> Second, looks pretty good. Are you using any kind of weighted sampling?
> A
> good weighting technique can reduce the number of lights needed to get
> good
> results. I have been working on a lightdome macro that creates
> environment
> lighting from HDRs for quite some time now (not quite made it public, a
> few
> more tweaks maybe). Within the last month or so of development, I added
> area light support and found it worked out quite nicely. With point
> lights, I was using about 256 (2^8) light sources with pretty good
> results,
> but still had some artifacting visible depending on the probe used. With
> area lights, I found I could get similar results, but with less
> artifacting
> with as little as 32 (2^5) 3x3 area lights.
>
> I would like to see your scene perhaps to see how my lighting macro
> performs.
>
> If you need any further information on this, I'll see what I can do (I've
> been quite busy at non-POV lately, so have been here less frequently
> recently).
>
> I still hope to release my lighting macro at some point, I just have to
> convince myself that I'm satisfied with its operation.
>
> -tgq
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
