I am currently working on a model of the solar system. Is there a way to
make the planets leave a trail as they move and/or define an elipse in the
shape of the orbits? I'm using astronomically correct formulae to calculate
the planetary positons, so just cylinders or tori won't work.

thanks,
OpalPlanet

Post a reply to this message

OpalPlanet wrote:
> I am currently working on a model of the solar system. Is there a way
> to make the planets leave a trail as they move and/or define an
> elipse in the shape of the orbits? I'm using astronomically correct
> formulae to calculate the planetary positons, so just cylinders or
> tori won't work.

If you place a sufficiently large number of tiny spheres along your path, it 
will look like a solid tube or string that follows your path. You can place 
then using a #while loop.

Alternatively you can look into sphere_sweeps with a sifficiently large 
number of control points along your path, again placed with a #while loop.

Rune
-- 
http://runevision.com

Post a reply to this message

A merge or union of cylinders will most probably give better results in less
render time than both methods described above (all might be worth a try
though)

Regards Roman

Post a reply to this message

Roman Reiner wrote:
> A merge or union of cylinders will most probably give better results
> in less render time than both methods described above (all might be
> worth a try though)

Yes, agreed. I don't know why I forgot about that option.

Merge can be very slow with a high number of objects though, so if a 
semi-transparent path is desired, sphere_sweeps may be faster after all, 
though I haven't compared results myself. If a semi-transparent path is not 
needed, union should definitely be used rather than merge.

Rune
-- 
http://runevision.com

Post a reply to this message

Rune, I was poking around your website and I found the particle system.
Could I just make each of the planets an "emitter" and leave a trail that
way?

-OpalPlanet

"Rune" <new### [at] runevisioncom> wrote:
> Roman Reiner wrote:
> > A merge or union of cylinders will most probably give better results
> > in less render time than both methods described above (all might be
> > worth a try though)
>
> Yes, agreed. I don't know why I forgot about that option.
>
> Merge can be very slow with a high number of objects though, so if a
> semi-transparent path is desired, sphere_sweeps may be faster after all,
> though I haven't compared results myself. If a semi-transparent path is not
> needed, union should definitely be used rather than merge.
>
> Rune
> --
> http://runevision.com

Post a reply to this message

I think sphere_sweep would work better, but i am having difficultly placing
the control points. I have .txt data files with <t,x,y,z> data for all the
planets, and i wanted to read that in and use each pint as one of the
control points. I'm new to this, but here is my best go at using a while
loop:


//to make the paths
#declare pathcount=1;
#while(pathcount <= num_planets)

  #switch(pathcount)
    #case(1)                  //Mercury
      #declare n = 0;
      #while( n < cnt)
       #read(mercury,tt,xx,yy,zz)
       #declare n = n +1;
      #end
      #render concat("Read up to file line ",str(n,6,0),"n")
   #break

    #case(2)                  //Venus
      #declare n = 0;
      #while( n < cnt)
       #read(venus,tt,xx,yy,zz)
       #declare n = n +1;
      #end
    #break

    #case(3)                  //Earth
      #declare n = 0;
      #while( n < cnt)
       #read(earth,tt,xx,yy,zz)
       #declare n = n +1;
      #end
   #break

   #case(4)                  //Mars
      #declare n = 0;
      #while( n < cnt)
       #read(mars,tt,xx,yy,zz)
       #declare n = n +1;
      #end
    #break
       #end

 sphere_sweep {
 quadratic_spline cnt,
 #declare n = 0;
 #while ( n<=cnt)
 <xx,yy,-zz>, .01
 #declare n = n +1;
 #end
  tolerance 0.1
  texture{pigment {White}
 finish {ambient 1}
 no_shadow
 }
 }

 #end

 #declare pathcount = pathcount +1;

#end//end paths


Obviously, not working.

Help, please?
OpalPlanet


"Rune" <new### [at] runevisioncom> wrote:
> Roman Reiner wrote:
> > A merge or union of cylinders will most probably give better results
> > in less render time than both methods described above (all might be
> > worth a try though)
>
> Yes, agreed. I don't know why I forgot about that option.
>
> Merge can be very slow with a high number of objects though, so if a
> semi-transparent path is desired, sphere_sweeps may be faster after all,
> though I haven't compared results myself. If a semi-transparent path is not
> needed, union should definitely be used rather than merge.
>
> Rune
> --
> http://runevision.com

Post a reply to this message

OpalPlanet wrote:
> I think sphere_sweep would work better, but i am having difficultly
> placing the control points. I have .txt data files with <t,x,y,z>
> data for all the planets, and i wanted to read that in and use each
> pint as one of the control points. I'm new to this, but here is my
> best go at using a while loop:

>  #switch(pathcount)
>    #case(1)                  //Mercury
>      #declare n = 0;
>      #while( n < cnt)
>       #read(mercury,tt,xx,yy,zz)
>       #declare n = n +1;
>      #end
>      #render concat("Read up to file line ",str(n,6,0),"n")
>   #break

Hmm.

What is tt, xx, yy and zz ? They would need to be arrays when you want to 
store many points in them.

So you would #declare xx, yy, zz and tt as arrays with size cnt (I presume 
cnt is #declared elsewhere).

Then you'd use:

       #read(mercury,tt[n],xx[n],yy[n],zz[n])

And when you want to use the points:

 #while ( n<cnt)
 <xx[n],yy[n],-zz[n]>, .01
 #declare n = n +1;
 #end

I'm a bit rusty with File I/O in POV-Ray, so perhaps someone can correct me 
if I'm wrong.

Rune
-- 
http://runevision.com

Post a reply to this message

OpalPlanet wrote:
> Rune, I was poking around your website and I found the particle
> system. Could I just make each of the planets an "emitter" and leave
> a trail that way?

Yes, that would be possible, depending on what effect you want. But then you 
need to know the emitters' positions at any given point in time - not just 
the current clock value. The particle system need to know the positions at 
other lock values than the current one to work correctly. This may be 
cumbersome if you get your positions from a list of points. On the other 
hand, you could load all the points into a spline function and use that one 
for the emitter positions.

Rune
-- 
http://runevision.com

Post a reply to this message