 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Tracers!
After removing my additional 64 megs module due to frequent crashes, I
tested the performance with the remaining 256 megs (on an AMD K6-II/380
MHz) by placing randomly 11, 000 of my plastic mouse wheels. Strangely,
there is a concentration of objects near the origin (camera location is
<0, 0.1, -0.4>, looking at <0, 0, 0>), though there are no quadratic
terms containing the random variable...
Rendering time: about 5:30 h, peak memory use: 309 megs
The next step would be a collision detector...
See you in Khyberspace -
http://www.geocities.com/electricafghan/index-e.html
Afghanistan Chronicle: http://www.ndh.net/home/bleimann/
Yadgar
Post a reply to this message
Attachments:
Download 'mousewheel09.jpg' (293 KB)
Preview of image 'mousewheel09.jpg'
|
|
| |
| |
|
|
From: JRG
Subject: Re: 11,000 Plastic Mouse Wheels (800 x 600, 293 KB)
Date: 8 Nov 2001 16:59:02
Message: <3beb0026@news.povray.org>
|
|
|
| |
| |
|
|
Yadgar wrote:
>Strangely,
> there is a concentration of objects near the origin (camera location is
> <0, 0.1, -0.4>, looking at <0, 0, 0>), though there are no quadratic
> terms containing the random variable...
If you're placing the wheels with the *orbit technique* (i.e. translate
x*radius*rand() rotate 360*rand()*y) you have to expect this, since every
radius is equally probable so the smaller the radius the smaller the circle
you put your objects on.
--
Jonathan.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What is your method for placing the wheels?
Fernando.
"Yadgar" <j.b### [at] ndh net> wrote in message
news:3BEB0AA3.FCEB55FF@ndh.net...
> Hi Tracers!
>
> After removing my additional 64 megs module due to frequent crashes, I
> tested the performance with the remaining 256 megs (on an AMD K6-II/380
> MHz) by placing randomly 11, 000 of my plastic mouse wheels. Strangely,
> there is a concentration of objects near the origin (camera location is
> <0, 0.1, -0.4>, looking at <0, 0, 0>), though there are no quadratic
> terms containing the random variable...
>
> Rendering time: about 5:30 h, peak memory use: 309 megs
>
> The next step would be a collision detector...
>
> See you in Khyberspace -
> http://www.geocities.com/electricafghan/index-e.html
> Afghanistan Chronicle: http://www.ndh.net/home/bleimann/
>
> Yadgar
>
>
>
>
----------------------------------------------------------------------------
----
Post a reply to this message
|
|
| |
| |
|
|
From: Skip Talbot
Subject: Re: 11,000 Plastic Mouse Wheels (800 x 600, 293 KB)
Date: 8 Nov 2001 17:28:35
Message: <3beb0713$1@news.povray.org>
|
|
|
| |
| |
|
|
What is a good way to do collision testing? Approximate the object with
an enclosing box? And then how do you check it for intersections?
Also, is there a formula or macro out there can fill and only fill a
perspective view? Having objects outside the perspective projectors omitted
would optimize parse time.
--
Skip
Yadgar <j.b### [at] ndhnet> wrote in message
news:3BEB0AA3.FCEB55FF@ndh.net...
> Hi Tracers!
>
> After removing my additional 64 megs module due to frequent crashes, I
> tested the performance with the remaining 256 megs (on an AMD K6-II/380
> MHz) by placing randomly 11, 000 of my plastic mouse wheels. Strangely,
> there is a concentration of objects near the origin (camera location is
> <0, 0.1, -0.4>, looking at <0, 0, 0>), though there are no quadratic
> terms containing the random variable...
>
> Rendering time: about 5:30 h, peak memory use: 309 megs
>
> The next step would be a collision detector...
>
> See you in Khyberspace -
> http://www.geocities.com/electricafghan/index-e.html
> Afghanistan Chronicle: http://www.ndh.net/home/bleimann/
>
> Yadgar
>
>
>
>
----------------------------------------------------------------------------
----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If you're placing the objects in a way similar to this:
#declare r = rand(myseed)*maxradius;
#declare angle = rand(myseed)*360;
translate vrotate(x*r,angle*y);
then you'll have to change the "r" statement to this in order to remove the
concentration:
#declare r = rand(myseed)^.5*maxradius;
And that should spread it out evenly.
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
"Yadgar" <j.b### [at] ndhnet> wrote in message
news:3BEB0AA3.FCEB55FF@ndh.net...
> Hi Tracers!
>
> After removing my additional 64 megs module due to frequent crashes, I
> tested the performance with the remaining 256 megs (on an AMD K6-II/380
> MHz) by placing randomly 11, 000 of my plastic mouse wheels. Strangely,
> there is a concentration of objects near the origin (camera location is
> <0, 0.1, -0.4>, looking at <0, 0, 0>), though there are no quadratic
> terms containing the random variable...
>
> Rendering time: about 5:30 h, peak memory use: 309 megs
>
> The next step would be a collision detector...
>
> See you in Khyberspace -
> http://www.geocities.com/electricafghan/index-e.html
> Afghanistan Chronicle: http://www.ndh.net/home/bleimann/
>
> Yadgar
>
>
>
>
----------------------------------------------------------------------------
----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Now make them not intersect :)
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
From: Gilles Tran
Subject: Re: 11,000 Plastic Mouse Wheels (800 x 600, 293 KB)
Date: 9 Nov 2001 04:48:09
Message: <3beba659$1@news.povray.org>
|
|
|
| |
| |
|
|
3beb0713$1@news.povray.org...
> Also, is there a formula or macro out there can fill and only fill a
> perspective view? Having objects outside the perspective projectors
omitted
> would optimize parse time.
There's one in the makestacks.inc file in the advanced/blocks 3.5 directory.
A rectangle mesh is created that fits the screen exactly and then the trace
function is used to test whether the camera-to-object vector meets the
"screen".
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
From: Yadgar
Subject: Re: 11,000 Plastic Mouse Wheels (800 x 600, 293 KB)
Date: 9 Nov 2001 19:19:53
Message: <3BEC7965.BBB7E6E8@ndh.net>
|
|
|
| |
| |
|
|
JRG schrieb:
> Yadgar wrote:
> >Strangely,
> > there is a concentration of objects near the origin (camera location is
> > <0, 0.1, -0.4>, looking at <0, 0, 0>), though there are no quadratic
> > terms containing the random variable...
>
> If you're placing the wheels with the *orbit technique* (i.e. translate
> x*radius*rand() rotate 360*rand()*y) you have to expect this, since every
> radius is equally probable so the smaller the radius the smaller the circle
> you put your objects on.
>
> --
> Jonathan.
No, my method is:
r=seed(3482) // seed values only examples!
a=seed(2321)
radius=rand(r)*2
ang=rand(a)*360
...
translate <radius*sin(ang*(pi/180)), 0, radius*cos(ang*(pi/180))>
...
Post a reply to this message
|
|
| |
| |
|
|
From: Trevor Quayle
Subject: Re: 11,000 Plastic Mouse Wheels (800 x 600, 293 KB)
Date: 9 Nov 2001 21:29:07
Message: <3bec90f3@news.povray.org>
|
|
|
| |
| |
|
|
> No, my method is:
>
> r=seed(3482) // seed values only examples!
> a=seed(2321)
>
> radius=rand(r)*2
> ang=rand(a)*360
>
> ...
>
> translate <radius*sin(ang*(pi/180)), 0, radius*cos(ang*(pi/180))>
>
> ...
hmm... several points of interest here:
1) sin(ang*(pi/180)), i realize you are converting the angle to radians for
use in the sin() function, are you aware that the function radians(ang)
would do this?
2)why convert the angle and rad to coordinates instead of doing this:
translate x*radius
rotate y*ang
or if you want the object to maintain its original rotation:
rotate -y*ang
translate x*radius
rotate y*ang
3) as others have mentioned, and from the method you are using, you should
expect a large concentration in the centre, to spread out more evenly use:
radius=sqrt(rand(r))*2
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
