Okay, I'm trying to randomly distribute objects, using trace, on a sphere.

So, I do something like:

RotZ = 180*rand(R1)
RotY = 360*rand(R1)
Trans = transform(translate y*10 rotate z*RotZ rotate y*RotY)
TVec = vtransform(<0,0,0>, Trans)
Inter = trace(Ob, TVec, -TVec)


The trouble is that I end up with a bunching of objects at the poles for all the
obvious reasons, so the question is, how do I best avoid this? I assume it's
something like:
ZRotFac = 1 + pow(abs((ZRot/90)-1),2);
ZRot = ZRot * ZRotFac

But,

a) is this correct? (well, it's not, afaik - the range 1..2 is too limited imho)
b) if not, what is?

--
#macro A(V,B,C,R)#while(B-256)#if(V-128/B>=0)sphere{0,.5translate<C-4R-1,9>
pigment{rgb<1-C/8R/2C/8>}}#local V=V-128/B;#end#local B=B*2;#local C=C+1;#
end#end A(234,1,0,2)A(85,1,0,1)A(81,1,0,0)light_source{-5 1}//Tom Melly

Post a reply to this message

I've come across the same problem some time ago,
so I implemented a macro which calculated an
electrostatic-repulsion algorithm. Some animations of
this macro can be found on my website.

If you want the code, I can see if I have to clean
the code a little or if I can send it to you right
away, just give me an email-adress.

Regards,
Tim


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> Okay, I'm trying to randomly distribute objects, using trace, on a sphere.
>
> So, I do something like:
>
> RotZ = 180*rand(R1)
> RotY = 360*rand(R1)
> Trans = transform(translate y*10 rotate z*RotZ rotate y*RotY)
> TVec = vtransform(<0,0,0>, Trans)
> Inter = trace(Ob, TVec, -TVec)
>
>
> The trouble is that I end up with a bunching of objects at the poles for
all the
> obvious reasons, so the question is, how do I best avoid this? I assume
it's
> something like:
> ZRotFac = 1 + pow(abs((ZRot/90)-1),2);
> ZRot = ZRot * ZRotFac
>
> But,
>
> a) is this correct? (well, it's not, afaik - the range 1..2 is too limited
imho)
> b) if not, what is?
>

Post a reply to this message

On Tue, 15 Oct 2002 12:03:11 +0100, "Tom Melly" <tom### [at] tomandlucouk> wrote:
> a) is this correct? (well, it's not, afaik - the range 1..2 is too limited imho)
> b) if not, what is?

My answer is not real answer but ... there is a macro in rand.inc include file
in standard distribution called VRand_On_Sphere.

ABX

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3dabfad8@news.povray.org...
> I've come across the same problem some time ago,
> so I implemented a macro which calculated an
> electrostatic-repulsion algorithm. Some animations of
> this macro can be found on my website.
>
> If you want the code, I can see if I have to clean
> the code a little or if I can send it to you right
> away, just give me an email-adress.
>

Probably overkill in this case ("electrostatic repulsion algorithm"? Yoiks!) -
I've got some close approximations working (well, good enough for gov. work).,
but many thanks for the offer.

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:rkunqu4ivtu7928rrf12ti4jo7jn8u86r6@4ax.com...

> My answer is not real answer but ... there is a macro in rand.inc include file
> in standard distribution called VRand_On_Sphere.
>

Ah, many thanks.....

Eep - I thought it might give me a clue, but I can't understand it at all. I
could rewrite some stuff to allow me to use it in this particular instance, but
that won't be as much fun as actually learning something....

Post a reply to this message

I'm not sure if its overkill, depends on what
you're trying to achieve. Still, the macro is very
easy to handle and needs to be run only once,
the data is then saved and can be loaded with
my I/O-Macros (which are available on my website).

But it depends on the amount of objects you're trying
to spread, as always with algorithms pending on amount...

Regards,
Tim

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

>
> Probably overkill in this case ("electrostatic repulsion algorithm"?
Yoiks!) -
> I've got some close approximations working (well, good enough for gov.
work).,
> but many thanks for the offer.
>

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3dac02a1$1@news.povray.org...
> I'm not sure if its overkill, depends on what
> you're trying to achieve. Still, the macro is very

Branch coral (well, distributing the coral) - I've posted an image to
binaries.images

Post a reply to this message

Maybe this one from Mike Andrews last year might make some sense. Sure is
confusing to me though.

news://povray.org/3B97457B.26C14AE4@reading.ac.uk

That randomly distributed point macro ABX brought up, VRand_On_Sphere() is
of course 'random', and looking at that now I don't know how to go about
derandomizing it. Trying to here and I get nonuniform distribution and
nothing better.

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3dabf5ef$1@news.povray.org...

Hmm, this seems to work for a hemisphere (which is all I need - although I'm
going to try and figure out how to make it work with any specified max angle).

// okay where MZRot = 90
#local ZRot = pow(rand(Rand1),0.5) * MZRot;
#local YRot = rand(Rand1) * MYRot;

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3dac1e3c@news.povray.org...
>
> Hmm, this seems to work for a hemisphere (which is all I need - although I'm
> going to try and figure out how to make it work with any specified max angle).
>
> // okay where MZRot = 90
> #local ZRot = pow(rand(Rand1),0.5) * MZRot;
> #local YRot = rand(Rand1) * MYRot;
>


and this (rather kludgy) approach seems to work for a specified MZRot:

    #local ZRot = pow(rand(Rand1),0.5) * 90;
    #local YRot = MYRot*rand(Rand1);
    #if(rand(Rand1)<0.5)
      #local ZRot = 180 - ZRot;
    #end
    #if(ZRot <= MZRot)
            .... position coral
            ..... increment counter
    #end

Post a reply to this message