POV-Ray : Newsgroups : povray.newusers : random orientation Server Time
1 Nov 2024 15:24:48 EDT (-0400)
  random orientation (Message 1 to 2 of 2)  
From: wizkidguy
Subject: random orientation
Date: 16 Apr 2005 23:15:00
Message: <web.4261d4aa58c5d9dac5f5c9d90@news.povray.org>
Can any one explain or give a sample of a random seed of toruses around a
layer? I am trying to learn the basics of pov-ray and am trying to make a
bowl of cereal and i want to add the cereal using a random seed instead of
individually makng the cereal. thanks for any help with this


Post a reply to this message

From: Chris B
Subject: Re: random orientation
Date: 17 Apr 2005 17:50:59
Message: <4262da43$1@news.povray.org>
"wizkidguy" <gov### [at] msncom> wrote in message
news:web.4261d4aa58c5d9dac5f5c9d90@news.povray.org...
> Can any one explain or give a sample of a random seed of toruses around a
> layer? I am trying to learn the basics of pov-ray and am trying to make a
> bowl of cereal and i want to add the cereal using a random seed instead of
> individually makng the cereal. thanks for any help with this
>
>

There are a few ways to do this, but I'm not sure it's the easiest thing to
start on if you're trying to learn the basics of POV-Ray.
I've posted an example on povray.binaries.scene-files. If your know any
programming languages then you'll probably be able to follow it easily
enough.

It uses the rand() function to move a torus away from the origin. It then
uses it again to rotate it so that the pieces of cereal are distributed
randomly in a disc.
That bit is actually quite simple, but if you just do that you end up with
bits of cereal slicing through each other in an unatural sort of way.

The tricky bit is detecting and avoiding collisions. The example on
povray.binaries.scene-files checks each new piece of cereal against all
previously defined pieces of cereal by doing an intersection and measuring
the size of the result. Unfortunately this isn't very accurate (at least in
POVRay 3.5 that I'm using) and therefore the example also steps through the
points between the minimum extent of the intersection object and the maximum
extent of the intersection object, looking for points that are inside the
intersection object. If it finds a collision it moves the new piece of
cereal to somewhere else and checks that position for collisions until it
finds somewhere where it doesn't intersect with anything else.

This gets exponentially more expensive on machine resource as you increase
the number of objects.
The example as-is (70 pieces of cereal) took about half a minute to render
on my 600MHz machine. If you increase the number of pieces to 100 it goes up
to over a minute.

Hope this helps,
Chris B.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.