Hi :)

i have two equations of an ellipse in polar form as follows:

f(theta)=(1-0.01671^2) / (1+0.01671*cos(theta-1.7968))

and

f(theta)=(0.937(1-0.232^2)) / (1+0.232*cos(theta-5.22))

where theta is the angle in radians, that i would like to have pov
generate the output of by placing a sphere every once in a while. 

these equations are supposed to represent a planet's orbit as well as an
asteroids orbit. at 2 values for theta, they collide. 

i have never used macros before, but i based my code on one of the
sample files. i am going to post the resulting image in
.binaries.images. The source is attached. I know there is a scene-files
group, but then i'd have all kinds of stuff to spread out. 

basically, there are two problems, the blue path representing the planet
has strange, nearly flat, sections. The grey path, representing the
asteroid, has a very uncertain path alltogether :) And furthermore, two
collision points aren't evident. These are what the whole project is
about. and i calculated them in a different program. ths whole povray
stuff is extra. well, i hope someone can enlighten me.

thanks,
ross

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

Ross Litscher wrote:
> 
> Hi :)
> 
> i have two equations of an ellipse in polar form as follows:
> 
> f(theta)=(1-0.01671^2) / (1+0.01671*cos(theta-1.7968))
> 
> and
> 
> f(theta)=(0.937(1-0.232^2)) / (1+0.232*cos(theta-5.22))
> 
> where theta is the angle in radians, that i would like to have pov
> generate the output of by placing a sphere every once in a while.
> 
> these equations are supposed to represent a planet's orbit as well as an
> asteroids orbit. at 2 values for theta, they collide.

If you take a look at the VFAQ under the section "how do I rotate the
camera around the origin" Warp has added a section using sin/cos for
changing a circular path to an elliptical path. Just take the code
from the camera location section and move it into a translate function.
Also instead of using the clock to increment the location use a while
loop to increment the objects position.

http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#camerarotation

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken wrote:

> If you take a look at the VFAQ under the section "how do I rotate the
> camera around the origin" Warp has added a section using sin/cos for
> changing a circular path to an elliptical path. Just take the code
> from the camera location section and move it into a translate function.
> Also instead of using the clock to increment the location use a while
> loop to increment the objects position.
> 
> 

this seems cleaner, but this doesn't seem as intuitive. I mean, how
exactly does this make things work better? (mind you, i havn't tried
this suggested method yet) The whole idea of a function is that you put
in a value and it returns another value. if these are in fact functions
describing ellipses(i assume they are, they were given and proclaimed
ellipses), then i would assume the output should look like an ellipse.
The blue one *kind of* does, the grey one not at all. 

if there is something wrong with the manner in which I implemeted the
method I chose, could you please explain? i have not used macros before,
and I have never used pov in this (mathematical) way. to me though, it
feels like given a function f(theta), for a value theta the function
returns a distance from the origin. using theta and that returned value,
it should be simple to place a sphere there. 

maybe I am entirely wrong, i'm just a youngin anyway. 

thanks for offering help,
ross

Post a reply to this message

i changed the following:

my_sphere scale to 0.005 instead of .3 (i think it was),
#declare theta = theta + 0.05 for both macros,
and
camera { location <0,1,-2>
	look_at <0,0,0>
	}

this gives a better resolution of what the function is doing, and causes
even more confusion.


dern. looks like I'm not going to bed just yet.

Post a reply to this message

I don't know why you are right, but you are :]

thanks for the help. I have a very pretty looking plot now of the
emminent destruction of our fair planet

Post a reply to this message

Ross Litscher wrote:
> 
> I don't know why you are right, but you are :]
> 
> thanks for the help. I have a very pretty looking plot now of the
> emminent destruction of our fair planet

I don't know why it works either but glad to have helped.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Wasn't it Ross Litscher who wrote:
>Hi :)
>
>i have two equations of an ellipse in polar form as follows:
>
>f(theta)=(1-0.01671^2) / (1+0.01671*cos(theta-1.7968))
>
>and
>
>f(theta)=(0.937(1-0.232^2)) / (1+0.232*cos(theta-5.22))
>
>where theta is the angle in radians, that i would like to have pov
>generate the output of by placing a sphere every once in a while. 
>
>these equations are supposed to represent a planet's orbit as well as an
>asteroids orbit. at 2 values for theta, they collide. 
>
>i have never used macros before, but i based my code on one of the
>sample files. i am going to post the resulting image in
>.binaries.images. The source is attached. I know there is a scene-files
>group, but then i'd have all kinds of stuff to spread out. 
>
>basically, there are two problems, the blue path representing the planet
>has strange, nearly flat, sections. The grey path, representing the
>asteroid, has a very uncertain path alltogether :) And furthermore, two
>collision points aren't evident. These are what the whole project is
>about. and i calculated them in a different program. ths whole povray
>stuff is extra. well, i hope someone can enlighten me.

Both problems are due to the fact that POV is inconsistent about the way
it uses angles. The ROTATE operation uses angles measured in degrees,
but its trig functions use angles measured in radians. You used degrees
throughout. 

If you replace both occurrences of "cos(theta..." by "cos(theta/r_d..."
(you've already declared r_d to be 180/Pi) then both orbits become nice
smooth ellipses and the two collision points become clearly visible.

-- 
Mike Williams * ##
Gentleman of Leisure

Post a reply to this message

In article <WEU### [at] econymdemoncouk>, Mike Williams 
<mik### [at] econymdemoncouk> wrote:

> If you replace both occurrences of "cos(theta..." by "cos(theta/r_d..."
> (you've already declared r_d to be 180/Pi) then both orbits become nice
> smooth ellipses and the two collision points become clearly visible.

Alternately, you could use the radians() and degrees() functions to 
convert between the two. This way is easier to understand(when you come 
back to your code later) and doesn't require a variable like "r_d" to be 
declared. These functions are built in to the official POV:

"degrees(A) Convert radians to degrees. Returns the angle measured in 
degrees whose value in radians is A . Formula is  degrees=A/pi*180.0 ."

"radians(A) Convert degrees to radians. Returns the angle measured in 
radians whose value in degrees is A . Formula is  radians=A*pi/180.0."

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Mike Williams wrote:
> 
> Both problems are due to the fact that POV is inconsistent about the way
> it uses angles. The ROTATE operation uses angles measured in degrees,
> but its trig functions use angles measured in radians. You used degrees
> throughout.
> 
> If you replace both occurrences of "cos(theta..." by "cos(theta/r_d..."
> (you've already declared r_d to be 180/Pi) then both orbits become nice
> smooth ellipses and the two collision points become clearly visible.
> 


thanks for clearing this up. is there a logical reason for the
inconsistence?


also, thanks chris for pointing out that there are functions for
converting between degrees and radians. 


ross

Post a reply to this message

In article <38A98347.3FCAB042@osu.edu>, Ross Litscher 
<lit### [at] osuedu> wrote:

> thanks for clearing this up. is there a logical reason for the
> inconsistence?

Probably this: the standard C library uses radians, and the functions 
simply provide a way to access those, but it is easier to manipulate 
objects in degrees. Radians seem to be more common with math, so they 
were kept for the functions.

BTW, I remember seeing a patch which provided degree-based trig 
functions, but I don't remember seeing it in MegaPOV. Which would be 
strange, since it was included in the MultiPatch...
Does anyone know about the status of this patch? I think the author was 
going to separate it from the rest of his patch work, maybe dispersion.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message