I got interested in m1j's post about "dome lighting" based on HDRI maps 
(http://news.povray.org/povray.binaries.images/thread/%3Cweb.43912795ae23e4252f222b3b0%40news.povray.org%3E/)

so I had a try at it (using my own code however, based on a geodesic dome 
macro I wrote many years ago) with impressive results.

HDRI2a.jpg shows a scene using HDRI with radiosity lighting (medium-low 
quality settings though)
HDRI2c.jpg shows the same scene using the dome lighting based on the HDRI 
(with a threshold limit)
the rest use the dome lighting using different HDRI maps.  As a note, each 
took on average 10mins to render (no AA or rad)

-tgq

Post a reply to this message

Attachments:
Download 'HDRI2a.jpg' (62 KB) Download 'HDRI2c.jpg' (74 KB) Download 'HDRI2d.jpg' (100 KB) Download 'HDRI2e.jpg' (87 KB) Download 'HDRI2f.jpg' (82 KB)

Preview of image 'HDRI2a.jpg'

Preview of image 'HDRI2c.jpg'

Preview of image 'HDRI2d.jpg'

Preview of image 'HDRI2e.jpg'

Preview of image 'HDRI2f.jpg'

How many lights are being used in one of these scenes? Are we talking
someing along that lines of an icosahedron of lights, or a 8v dome, or...?

Great stuff though. The indoor/warehouse is wonderful.

-s
5TF!

Post a reply to this message

Somewhere on average between 200-600 lights for each image.

The dome is basically a sphere subdivied into triangles (see image, sd level 
3,4,5).

The actual number of lights depends on the level of subdivision and the 
light threshold.  Not every point of the dome has a light, as render times 
would get horrendous for little increase.


"stm31415" <sam### [at] cscom> wrote in message 
news:web.43a2d589e93c309a9b0dd50e0@news.povray.org...
> How many lights are being used in one of these scenes? Are we talking
> someing along that lines of an icosahedron of lights, or a 8v dome, or...?
>
> Great stuff though. The indoor/warehouse is wonderful.
>
> -s
> 5TF!
>

Post a reply to this message

Attachments:
Download 'Testing.png' (44 KB)

Preview of image 'Testing.png'

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Somewhere on average between 200-600 lights for each image.
>
> The dome is basically a sphere subdivied into triangles (see image, sd level
> 3,4,5).
>
> The actual number of lights depends on the level of subdivision and the
> light threshold.  Not every point of the dome has a light, as render times
> would get horrendous for little increase.
>
>



Right. Believe me, I'm a big Fuller fan. I just didn't know of what order
the dome was.  How few lights can be used before it becomes an
unintelligible mess? Obviously a full geodesic would only be the most
efficent distribution if the image was one color, which, of course, it is
not. That would be silly. Rather than simple threshold the lights (I assume
by that you mean it only places a light if the corresponding pixel(s)
is(are) bright enough), perhaps there is a better way - that is still a
relatively arbitrarily even distribution. I am thinking perhaps there is a
way to to a little processing and actually increase the density of the
lights in areas of greater brightness, thus reducing the need for large
numbers. Of course, then the geodesic distribution is useless, but some
sort of iterative process might do it- divide the image, proportion the
number of lights per division based on the average brightness, and repeat
for each division until each division has only one light. That would allow
for an exact number of lights to be used, and use them more effectively.
Oi. I don't have time for a new project now, but you've got me intrigued. I
don't know much about image processing with pov. Now I'll end up spending
my winter break learning that.

-s
5TF!

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> I got interested in m1j's post about "dome lighting" based on HDRI maps
>
(http://news.povray.org/povray.binaries.images/thread/%3Cweb.43912795ae23e4252f222b3b0%40news.povray.org%3E/)
> so I had a try at it (using my own code however, based on a geodesic dome
> macro I wrote many years ago) with impressive results.
>
> HDRI2a.jpg shows a scene using HDRI with radiosity lighting (medium-low
> quality settings though)
> HDRI2c.jpg shows the same scene using the dome lighting based on the HDRI
> (with a threshold limit)
> the rest use the dome lighting using different HDRI maps.  As a note, each
> took on average 10mins to render (no AA or rad)
>
> -tgq

Here is another one I did.

Here is my code:

//light dome from image.

#macro
DOMELITE(SP,HEMI,YANGLE,MULT,CLIPV,THRES,SSAMP,RAD,AREA,AS,LV,FNAME,FTYPE)
#switch(FTYPE )
  #case(0)
    #local PIMAGE = function {pigment{image_map {jpg FNAME}}}//grab image
  #break
  #case(1)
    #local PIMAGE = function {pigment{image_map {png FNAME}}}//grab image
  #break
  #case(2)
    #version unofficial megapov 1.21;
    #local PIMAGE = function {pigment{image_map {hdr FNAME}}}//grab image
  #break
#end
#local X = 0;
#while(X < (1-SP))
  #local Y = HEMI;
  #while(Y < 1-(SP*2))
    #local S = seed(10);

    #local CNT = 0;
    #local COL = PIMAGE(X,Y,0);
    #while (CNT < SSAMP)
           #local COL = (COL + PIMAGE(X+(rand(S)*SP),Y+(rand(S)*(SP)),0))/2;
           #local CNT = CNT + 1;
    #end
    #if(CLIPV.gray != 0) #local COL =
<min(COL.red,CLIPV.gray),min(COL.green,CLIPV.gray),min(COL.blue,CLIPV.gray)>;
#end
    #if(COL.gray > THRES)
      light_source{x*RAD color (COL*MULT)
        #if(LV) looks_like{sphere{x*RAD,2 pigment{color COL}}} #end
        #if(AREA) area_light  <AS, 0, 0> <0, 0, AS>   4, 4 adaptive 1
jitter  circular  orient  #end
        #if(COL.gray > 0.85) photons {refraction on reflection on} #end
        rotate z*(Y*180-90)
        rotate y*((1-X)*360+YANGLE)
        translate y*0.1
      }
    #end
  #local Y = Y + SP*2;
  #end
#local X = X + SP;
#end
#end

DOMELITE(0.04  /*SP*/, 0.5 /*HEMI*/, AG /*YANGLE*/, 0.035 /*MULT*/,1000000
/*CLIPV*/,0.1 /*THRES*/,30 /*SSAMP*/,100 /*RAD*/,yes /*AREA*/,20 /*AS*/,no
/*LV*/,IFNAME /*FNAME*/,2 /*FTYPE*/)

Post a reply to this message

Attachments:
Download 'building_d.jpg' (35 KB)

Preview of image 'building_d.jpg'

"m1j" <mik### [at] hotmailcom> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > I got interested in m1j's post about "dome lighting" based on HDRI maps
> >
(http://news.povray.org/povray.binaries.images/thread/%3Cweb.43912795ae23e4252f222b3b0%40news.povray.org%3E/)
> > so I had a try at it (using my own code however, based on a geodesic dome
> > macro I wrote many years ago) with impressive results.
> >
> > HDRI2a.jpg shows a scene using HDRI with radiosity lighting (medium-low
> > quality settings though)
> > HDRI2c.jpg shows the same scene using the dome lighting based on the HDRI
> > (with a threshold limit)
> > the rest use the dome lighting using different HDRI maps.  As a note, each
> > took on average 10mins to render (no AA or rad)
> >
> > -tgq
>
> Here is another one I did.
>

This one took about an hour because of the blured reflection.

My light domes average 100 to 800 lights. Basic scenes render 10 to 20 min.

Post a reply to this message

Attachments:
Download 'building_b.jpg' (37 KB)

Preview of image 'building_b.jpg'

Nice
From what I can gather from your code, is the light spacing based on the x-y 
coordinates of the un-wrapped HDRI?  This may cause you problems with lights 
close to the poles of the image as you would tend to get a higher density of 
lights in these areas, which is why I tried to do a geodesic dome 
configuration, to try to get a more even sampling around the dome.  I do 
like the supersampling idea, which I didn't try implementing.  One thing 
that you can do to help with the light brightness, is do 2 identical passes 
so you can get a light count on the first one and adjust the lights 
accordingly. BTW, I see you did get it macroed after all.  I would like to 
figure out some way to get better adaptive sampling.  With larger sampling 
spacing, you can miss smaller light sources and with finer sample spacing 
you can get too many lights, depending on the threshold level.  The random 
super sampling probably helps a bit with this.
My macro if you are interested:

//start
#macro MapLight(n,R,Map,SS,BR,TH, LI)
  #declare PIMAGE = function {pigment{image_map {hdr Map}}}
  union{
    #if (SS)
      sphere{0 R*1.01
        pigment {image_map {hdr MAP once interpolate 2 map_type 1} scale 
<1,1,-1>}
        finish {ambient BR diffuse 0}
      }
    #end
    #declare nL=pow(2,(n-1));
    #declare numL=0;
    #declare MaxB=0;
    #declare k=0; #while (k<=1)
      #declare i=-nL; #while (i<=nL)
        #declare nS=4*(nL-abs(i));
        #declare j=0; #while (j<=nS)
          #if (nS=0)
            #declare xp=0;
          #else
            #declare xp=2*j/nS-1;
          #end
            #declare yp=i/nL/2;
            #declare COL = PIMAGE(xp/2+0.5,yp+0.5,0);

            #if (COL.gray > MaxB) #declare MaxB=COL.gray; #end

            #if (COL.red>TH|COL.green>TH|COL.blue>TH)
              #if (k=0)
                #declare numL=numL+1;
              #else
                light_source{0 color (COL/numL)*LI fade_power 2 
fade_distance R translate<0,0,-R> rotate x*i*90/nL rotate y*j*360/nS rotate 
y*270}
              #end
            #end
        #declare j=j+1; #end
      #declare i=i+1; #end
    #declare k=k+1; #end
    #debug concat("NumLights:",str(numL,0,0),"/",str(2+pow(2,2*n),0,0)," 
(",str(numL/(2+pow(2,2*n))*100,0,1),"%)\n")
    #debug concat("MaxB-(",str(MaxB,0,3),")\n")
  }
#end
//end

I attached a few more scnes samples as well.
In the last one, I removed the HDRI sky sphere and used visible light 
sources instead to be able to see the distribution.

Post a reply to this message

Attachments:
Download 'HDRI2g.jpg' (81 KB) Download 'HDRI2h.jpg' (59 KB) Download 'HDRI2i.jpg' (38 KB) Download 'HDRI2.jpg' (65 KB)

Preview of image 'HDRI2g.jpg'

Preview of image 'HDRI2h.jpg'

Preview of image 'HDRI2i.jpg'

Preview of image 'HDRI2.jpg'

I was trying to find a way to decrease the lights at the top. The only way
My code could be changed for that is to randomly remove lights at an
increasing rate as the angle moves closer to the top. This is not a good
solution.

With the adition of the sub sampling your code looks like it is better. This
could be done by sampling at 2 or more levels deeper in subdivision but
placing lights at the undivided level. Also I added a photon statment to
see what that would be like. I am still working with the setting to try to
get it right.

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Nice
> From what I can gather from your code, is the light spacing based on the x-y
> coordinates of the un-wrapped HDRI?  This may cause you problems with lights
> close to the poles of the image as you would tend to get a higher density of
> lights in these areas, which is why I tried to do a geodesic dome
> configuration, to try to get a more even sampling around the dome.  I do
> like the supersampling idea, which I didn't try implementing.  One thing
> that you can do to help with the light brightness, is do 2 identical passes
> so you can get a light count on the first one and adjust the lights
> accordingly. BTW, I see you did get it macroed after all.  I would like to
> figure out some way to get better adaptive sampling.  With larger sampling
> spacing, you can miss smaller light sources and with finer sample spacing
> you can get too many lights, depending on the threshold level.  The random
> super sampling probably helps a bit with this.
> My macro if you are interested:
>
> //start
> #macro MapLight(n,R,Map,SS,BR,TH, LI)
>   #declare PIMAGE = function {pigment{image_map {hdr Map}}}
>   union{
>     #if (SS)
>       sphere{0 R*1.01
>         pigment {image_map {hdr MAP once interpolate 2 map_type 1} scale
> <1,1,-1>}
>         finish {ambient BR diffuse 0}
>       }
>     #end
>     #declare nL=pow(2,(n-1));
>     #declare numL=0;
>     #declare MaxB=0;
>     #declare k=0; #while (k<=1)
>       #declare i=-nL; #while (i<=nL)
>         #declare nS=4*(nL-abs(i));
>         #declare j=0; #while (j<=nS)
>           #if (nS=0)
>             #declare xp=0;
>           #else
>             #declare xp=2*j/nS-1;
>           #end
>             #declare yp=i/nL/2;
>             #declare COL = PIMAGE(xp/2+0.5,yp+0.5,0);
>
>             #if (COL.gray > MaxB) #declare MaxB=COL.gray; #end
>
>             #if (COL.red>TH|COL.green>TH|COL.blue>TH)
>               #if (k=0)
>                 #declare numL=numL+1;
>               #else
>                 light_source{0 color (COL/numL)*LI fade_power 2
> fade_distance R translate<0,0,-R> rotate x*i*90/nL rotate y*j*360/nS rotate
> y*270}
>               #end
>             #end
>         #declare j=j+1; #end
>       #declare i=i+1; #end
>     #declare k=k+1; #end
>     #debug concat("NumLights:",str(numL,0,0),"/",str(2+pow(2,2*n),0,0),"
> (",str(numL/(2+pow(2,2*n))*100,0,1),"%)n")
>     #debug concat("MaxB-(",str(MaxB,0,3),")n")
>   }
> #end
> //end
>
> I attached a few more scnes samples as well.
> In the last one, I removed the HDRI sky sphere and used visible light
> sources instead to be able to see the distribution.

Post a reply to this message

Attachments:
Download 'building.jpg' (17 KB)

Preview of image 'building.jpg'

I'm in the process of trying to implement subsampling and seeing what works
best.  Not sure whether its better to go with a random sampling or a fixed
subdivision.  I have added a type of adaptive subsampling that adds
additional lights, this is done in a fixed rectangular subdivision of each
vertex and its tributary area.  I'll post updated code when I get things a
bit more refined.

Ads a note for your routine, you may want to fix your subsamplig averaging
method (unless it's meant to work as you've made it).  The way you've done
it (ie iteratively adding a number then dividing by 2) doesn't give a true
average.  For example, for the series (7,5,3,1,224) you get 10.1, whereas
the average is 7.5.  You method gives more weighting to the numbers towrds
the end of the series. If you want to change this:

Instead of:
    #while (CNT < SSAMP)
           #local COL = (COL + PIMAGE(X+(rand(S)*SP),Y+(rand(S)*(SP)),0))/2;
           #local CNT = CNT + 1;
    #end

Try:
    #while (CNT < SSAMP)
           #local COL = (COL + PIMAGE(X+(rand(S)*SP),Y+(rand(S)*(SP)),0));
           #local CNT = CNT + 1;
    #end
    #local COL = COL/(SSAMP+1);


I'm looking forward to seeing more of your progress.

PS: I haven't tried adding photons, radiosity or AA yet as I'm not very
patient at seeing results...

-tgq

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> I'm in the process of trying to implement subsampling and seeing what works
> best.  Not sure whether its better to go with a random sampling or a fixed
> subdivision.  I have added a type of adaptive subsampling that adds
> additional lights, this is done in a fixed rectangular subdivision of each
> vertex and its tributary area.  I'll post updated code when I get things a
> bit more refined.
>
> Ads a note for your routine, you may want to fix your subsamplig averaging
> method (unless it's meant to work as you've made it).  The way you've done
> it (ie iteratively adding a number then dividing by 2) doesn't give a true
> average.  For example, for the series (7,5,3,1,224) you get 10.1, whereas
> the average is 7.5.  You method gives more weighting to the numbers towrds
> the end of the series. If you want to change this:
>
> Instead of:
>     #while (CNT < SSAMP)
>            #local COL = (COL + PIMAGE(X+(rand(S)*SP),Y+(rand(S)*(SP)),0))/2;
>            #local CNT = CNT + 1;
>     #end
>
> Try:
>     #while (CNT < SSAMP)
>            #local COL = (COL + PIMAGE(X+(rand(S)*SP),Y+(rand(S)*(SP)),0));
>            #local CNT = CNT + 1;
>     #end
>     #local COL = COL/(SSAMP+1);
>
>
> I'm looking forward to seeing more of your progress.
>
> PS: I haven't tried adding photons, radiosity or AA yet as I'm not very
> patient at seeing results...
>
> -tgq

I was just about to try a new method of placing the lights using:

#macro PSURFACE1(PS,U,V)
// Evaluates the Bezier triangle at (u,v).
{
    #local w = 1 - U - V;
    #local u2 = U * U;
    #local v2 = V * V;
    #local w2 = w * w;
    (w2*PSX[0] + (2*U*w)*PSX[1] + u2*PSX[2] + (2*U*V)*PSX[3] + v2*PSX[4] +
(2*V*w)*PSX[5]);
#end


Four of these placed around a hemisphere should produce the proper spacing.
Sub sampling would take place by setting a total sampling value then using
another value to set at what level in the total samplings the lights should
be placed. This will also make the total number of lights easier to get (I
think).

I have not started yet but will soon.

I did make the change to my averaging code you provided above. I had not
even considered that it would be different than a standard average. This
shows my lack in critical math knowledge.

Post a reply to this message