I've been attempting to model a 3d attractor in povray using the following code.


#declare Delta_T = 50000;
#declare T1 = 500000;
#declare T0 = T1 - Delta_T;

union {
#local pA = <3.0, 6.9, 4.2>;
#local Aleph = 0;
#while(Aleph <= 1000)
#debug concat(str(Aleph,0,0), "\n")
#local nA = <pA.x*pA.z*sin(.3*pA.x)-cos(.2*pA.y),
               pA.y*pA.x*sin(.5*pA.y)-cos(.4*pA.z),
               pA.z*pA.y*sin(.7*pA.z)-cos(.6*pA.x)>;
#local pA = nA;

sphere { pA, 0.05 }

#local Aleph = Aleph + 1;
#end
    }

I'm using a default pigment atm to lower the memory requirements, but it still
hangs after calculating all the positions.  I know it's looping through all the
calculations because of the debug statement, so I can't figure out why it hangs.
 my only thought is that it's trying to create bounding boxes for thousands of
tiny objects and having a conniption.
At the current setting of 1000 it hangs for several hours and does nothing. can
anyone advise me on this?

I'm running 3.7 beta 35 on a fujitsu lifebook with Ubuntu lucid and KDE

A.D.B.

Post a reply to this message

On 07/28/2010 10:34 PM, Anthony D. Baye wrote:
> I've been attempting to model a 3d attractor in povray using the following code.

didn't hang for me, however when i substituted:
#debug concat(vstr(3,pA,",",0,4), "\n")

into the code the vectors are ALL coming back as nan,nan,nan

Jim

Post a reply to this message

Am 29.07.2010 03:34, schrieb Anthony D. Baye:
> I've been attempting to model a 3d attractor in povray using the following code.
...
> I'm using a default pigment atm to lower the memory requirements, but it still
> hangs after calculating all the positions.  I know it's looping through all the
> calculations because of the debug statement, so I can't figure out why it hangs.
>   my only thought is that it's trying to create bounding boxes for thousands of
> tiny objects and having a conniption.
> At the current setting of 1000 it hangs for several hours and does nothing. can
> anyone advise me on this?

Doesn't sound anywhere close to convincing: A lousy 1000 spheres is 
nothing POV-Ray should have any trouble to bounding, and memory 
consumption is no higher than ~230 MByte (30 MByte more than what seems 
to be basic overhead), and both parsing and rendering times are sane on 
my machine (okay, it's an Intel i7 Quad with 6 GB RAM, but still...)

As it seems, the problem is rather that your attractor isn't very 
attractive: It marches off to infinity after ~10 iterations, and /that/ 
is apparently giving POV-Ray the bends ("try bounding /this/!").

BTW, for saving some memory (and possibly also speed up rendering) you 
may want to try using a blob instead of a union.

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> On 07/28/2010 10:34 PM, Anthony D. Baye wrote:
> > I've been attempting to model a 3d attractor in povray using the following code.
>
> didn't hang for me, however when i substituted:
> #debug concat(vstr(3,pA,",",0,4), "\n")
>
> into the code the vectors are ALL coming back as nan,nan,nan
>
> Jim

The problem might be an inferior school laptop, it is only a 32-bit machine.

When I try it on my desktop machine (Mac G5 quad-core 64-bit OS 10.4.11) it
seems to run, but I still get no good image. I have to use 10.6 because the new
beta only runs under 10.5+, apparently.

maybe it's something with beta 35a specifically, but I can't think what.

as for the attractor, I got the math from this site:

http://softologyblog.wordpress.com/category/chaos/page/2/

it's the Rampe3 Attractor.

A.D.B.

Post a reply to this message

On 07/29/2010 01:27 PM, Anthony D. Baye wrote:
> maybe it's something with beta 35a specifically, but I can't think what.

kind of doubt it ...

> as for the attractor, I got the math from this site:
> 
> http://softologyblog.wordpress.com/category/chaos/page/2/
> 
> it's the Rampe3 Attractor.

Nevertheless ... I'd check the math. I agree with clipkas' follow up (I
ran again and scrolled back farther) ... good luck ;-)

Post a reply to this message

Am 29.07.2010 18:27, schrieb Anthony D. Baye:

> as for the attractor, I got the math from this site:
>
> http://softologyblog.wordpress.com/category/chaos/page/2/
>
> it's the Rampe3 Attractor.

The site mentions that starting values should be initialized to <0,0,0>; 
other values may give "sane" sequences as well, but according to the 
formulas virtually anything outside the range <-2,-2,-2> to <2,2,2> 
(with possible exceptions very close to the coordinate axes) /will/ 
"explode" right away. So while the formula seems ok, your starting point 
<3.0,6.9,4.2> is definitely not.

Post a reply to this message

Am 30.07.2010 10:18, schrieb clipka:
> Am 29.07.2010 18:27, schrieb Anthony D. Baye:
>
>> as for the attractor, I got the math from this site:
>>
>> http://softologyblog.wordpress.com/category/chaos/page/2/
>>
>> it's the Rampe3 Attractor.
>
> The site mentions that starting values should be initialized to <0,0,0>;
> other values may give "sane" sequences as well, but according to the
> formulas virtually anything outside the range <-2,-2,-2> to <2,2,2>
> (with possible exceptions very close to the coordinate axes) /will/
> "explode" right away. So while the formula seems ok, your starting point
> <3.0,6.9,4.2> is definitely not.

The choice of the a,b,c,d,e,f parameters seems crucial, too: Even with 
<0,0,0> as the starting point, the chosen values make the sequence 
"explode" within a few iterations, while a=-.3 instead of +.3 already 
makes a significant difference (though the result is still dull, but 
that's a different story).

Post a reply to this message