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