> Hey, i had an idea for something pretty interesting but I am having
problems
> implementing it.  What i did was create a sphere with object media at the
> origin with a radius of five. That part was easy enough, but placing the
> lights is troubling me. I need the placement to be random, but at the same
> time the lights need to be on the inside of the sphere. If they go
outside,
> they light the sphere itself and that destroys the scene. So can anyone
help
> me?
>
> Thanks in advance.

My solution would be as follows:

#declare Seed=seed(1);

#declare
Random_Lightsource=vnormalize(<rand(Seed)*2-1,rand(Seed)*2-1,rand(Seed)*2-1>
)*rand(Seed)*5;

This would generate a random position ON a unit-sphere, but the radius gets
randomized to a value between 0 and 5 (rand(Seed)*5 at the end). If you need
to make sure that the lightsource is a certain distance in the sphere,
reduce the radius, if you want it to range from a certain distance of the
center, multiply with the following:

(rand(Seed)*(Max_Radius-Min_Radius)+Min_Radius)

Don't forget the brackets, cause Value*Value_2+Value_3 is something
different than Value*(Value_2+Value_3)!

This should parse faster than trying to randomly generate a position in a
box and THEN find if its in the sphere, cause it produces a position in the
sphere RIGHT AWAY.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.536 / Virus Database: 331 - Release Date: 03.11.2003

Post a reply to this message

Wesley Parker <wes### [at] verizonnet> wrote:
> this is kinda funny, i changed the amount of lights im going to use from 25
> to 250 (and increased the radius to 500) and its been parsing for the last
> 15 minutes o.O

  With 250 light sources the it will take enormous amounts of parsing
and specially rendering time anyways (but not placing the light sources,
but calculating light buffers).

  If you want to test the speed of the code, place small objects instead,
like tiny spheres.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Kurts <kur### [at] yahoofr> wrote:
> take a rayon
> take a random number from 0 to 360
> take an other random number from +90 to -90
> then just convert polar coordonates from this 3 number to rectangular <x,y,z>

> pretty simply

  You don't get an even distribution that way.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Tim Nikias v2.0 <tim.nikias (@) nolights.de> wrote:
> #declare
> Random_Lightsource=vnormalize(<rand(Seed)*2-1,rand(Seed)*2-1,rand(Seed)*2-1>
> )*rand(Seed)*5;

  Are you sure this produces an even distribution?-)

  By the way, you can do: <rand(Seed),rand(Seed),rand(Seed)>*2-1

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

> > #declare
> >
Random_Lightsource=vnormalize(<rand(Seed)*2-1,rand(Seed)*2-1,rand(Seed)*2-1>
> > )*rand(Seed)*5;
>
>   Are you sure this produces an even distribution?-)

Nah, not sure if this is even distribution. Would be, sorta, if the
rand-function would be TRULY random, but it suffices in most cases anyway.
Randomizing points in a box and then checking if its in the sphere wouldn't
produce even distribution either. So why not save the parsing time of
sorting out unnecessary points?

>   By the way, you can do: <rand(Seed),rand(Seed),rand(Seed)>*2-1

Hm, yeah, right. Can't remember when and how I came to do it this way...

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.536 / Virus Database: 331 - Release Date: 03.11.2003

Post a reply to this message

"Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote in message
news:3fa8d552@news.povray.org...

> Nah, not sure if this is even distribution. Would be, sorta, if the
> rand-function would be TRULY random, but it suffices in most cases anyway.
> Randomizing points in a box and then checking if its in the sphere wouldn't
> produce even distribution either. So why not save the parsing time of
> sorting out unnecessary points?

Ignoring the issue of rand-function and TRULY random, I suspect you're missing
the point.

Imagine a disk, now take a random distance along the radius, and then a random
rotation. You will get a disproportionate number of points near the center of
the disk. However, finding truly random points within a square that contains the
disk, and then checking whether they are inside the disk will produce a proper
random distrib. within the confines of the rand method.

You can see this yourself with the following code:

#include "colors.inc"

camera {
  location  <0.0, 0.0, -4.0>
  look_at   <0.0, 0.0,  0.0>
}

disc {
  <0, 0, 0>  // center position
  z,         // normal vector
  1.0,       // outer radius
  0.0        // optional hole radius
  pigment{Red}
  finish{ambient 1}
}

#local Count = 0;
#local MyRand = seed(2534);
#while(Count<1000)
  sphere{
    0,0.025
    translate y*rand(MyRand)
    rotate z*360*rand(MyRand)
    pigment{Green}
    finish{ambient 1}
  }
  #local Count = Count +1;
#end

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> Imagine a disk, now take a random distance along the radius, and then a random
> rotation. You will get a disproportionate number of points near the center of
> the disk.

  For the same reason the presented method of normalizing a random point
inside the cube will not give an even distribution of points on the
surface of the sphere. The points will be slightly more concentrated
on the direction of the corners of the box (because there are more points
at those directions than eg. in the direction of the main axes).
  Granted, this concentration difference is very small and probably
mostly unnoticeable, but if mathematical distribution evenness is
important, one should know this limitation.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

> Ignoring the issue of rand-function and TRULY random, I suspect you're
missing
> the point.
>
> Imagine a disk, now take a random distance along the radius, and then a
random
> rotation. You will get a disproportionate number of points near the center
of
> the disk. However, finding truly random points within a square that
contains the
> disk, and then checking whether they are inside the disk will produce a
proper
> random distrib. within the confines of the rand method.

Ah, okay, I get it. You mean with the box approach, the points in the
corners of the box, outside the sphere, will fall out, but in my case,
they'll be introduced into the sphere. Hence a larger distribution of points
in the "axis-corners" of the sphere, right?

Then you're both right about that. Still, depending on the amount of
lightsources required, I'd say there is no need to go into the hassle of the
more difficult approach with if-statements and all that. But that's probably
more an issue of taste, cause with random distribution, it *sometimes*
doesn't matter if its even or not...

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.536 / Virus Database: 331 - Release Date: 03.11.2003

Post a reply to this message

Tim Nikias v2.0 <tim.nikias (@) nolights.de> wrote:
> Ah, okay, I get it. You mean with the box approach, the points in the
> corners of the box, outside the sphere, will fall out, but in my case,
> they'll be introduced into the sphere. Hence a larger distribution of points
> in the "axis-corners" of the sphere, right?

  I actually rendered an image to see if the difference in distribution
is visible. I placed 20000 dots on the surface of a sphere using the
normalization method. The distribution is quite visible:

http://www.cs.tut.fi/~warp/images/test.jpg

> Then you're both right about that. Still, depending on the amount of
> lightsources required, I'd say there is no need to go into the hassle of the
> more difficult approach with if-statements and all that.

  It's no hassle to use the VRand_In_Sphere() macro in rand.inc.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

news:3fa85c48$1@news.povray.org...
> nah, i cant resist the urge to see how long it takes.
>
> 20 minutes and counting...

Turn off the light buffers: -ul on the command line.

G.

-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message