POV-Ray : Newsgroups : povray.newusers : Rollercoaster type maths (not possible in povray?) Server Time
1 Nov 2024 01:21:41 EDT (-0400)
  Rollercoaster type maths (not possible in povray?) (Message 1 to 10 of 27)  
Goto Latest 10 Messages Next 10 Messages >>>
From: CdeathJd
Subject: Rollercoaster type maths (not possible in povray?)
Date: 31 Jul 2006 19:00:00
Message: <web.44ce8ad119e69c80e2e0912a0@news.povray.org>
I'm using povray v3.6
im trying to make something of a rollercoaster, but cant figure it out at
all. I have a height field, n some atmospheric stuff in my scene, i also
have a start point and an end point. I also have a section of "track". Up
to this, everything is fine, but after this, povray refuses to work right,
i dont know why. In other programming languages, everything is fine, but
pov-ray wont compute!.

The way i understand making the track to be:
You have your first section, then your second section of track, which you
position over the first section, then turn it a little in either x,y,z or
either, in small amounts, then you move the piece forward repeat untill
your track is made.

PROBLEM: Pov ray doesn't have a command to move objects relative to their
current position AND ROTATION. I tried my method out, and the track was
flat, and completely curvless.

To get the camera rolling along the track i presume i'll need a array of 3d
coordinates of every track piece and its rotation, move the camera to the
track piece, turn it around to the same rotation as the track piece, then
move it "up" from the track.

FORESEEN PROBLEM: Pov ray doesn't have a command to move objects (the
camera) relative to their(its) current position AND ROTATION.

Also i tried to get the start and end point to be looking at each other and
this failed too. The start and end are basically two fancy open cylinders.

Note for the last problem i used the following method:
x1#=50
y1#=42.5
z1#=-212
x2#=350
y2#=42.5
z2#=240

angle2d=ATan2(x1-x2,z1-z2)

NOTE that only x and z are relevant, so this could be classed as a 2d
problem, but once again, it gives the answer -146 which is wrong, im not
exactly sure, but the correct value is something like 32.5 (not exactly
this but i used trial and error to get a rough idea

further info:
The "roller coaster doesn't HAVE to go round with physics such as gravity,
but if it makes things easier to include it please say so. I don't know why
this refuses to work in pov-ray and works in everything else, i think the
big let down is the lack of a move (with rotation) relevance command.


Post a reply to this message

From: Trevor G Quayle
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 31 Jul 2006 22:53:41
Message: <44cec235$1@news.povray.org>
"CdeathJd" <nomail@nomail> wrote in message 
news:web.44ce8ad119e69c80e2e0912a0@news.povray.org...
> I'm using povray v3.6
> im trying to make something of a rollercoaster, but cant figure it out at
> all. I have a height field, n some atmospheric stuff in my scene, i also
> have a start point and an end point. I also have a section of "track". Up
> to this, everything is fine, but after this, povray refuses to work right,
> i dont know why. In other programming languages, everything is fine, but
> pov-ray wont compute!.
>
> The way i understand making the track to be:
> You have your first section, then your second section of track, which you
> position over the first section, then turn it a little in either x,y,z or
> either, in small amounts, then you move the piece forward repeat untill
> your track is made.
>

It certainly should be possible, you just need to understand how pov SDL 
works with respect to objects.  Objects don't have their own local origin 
which they rotate and scale around, this is all done relative to the origin 
<0,0,0> no matter where in the scene the object is.  So you must think how 
the piece is made relative to the origin.  Typically, you would make the 
pieces at the origin, rotate them appriately, then move them to thier proper 
location.  You can also build sections of the track like this in groups, 
then rotate and move the whole group to it's final location, depending upon 
your particular needs.

-tgq

PS: Never assume something can't be done in POV.  Us hardcore POVers will do 
our best to try to find a solution no matter how simple or complex or die 
trying :D


Post a reply to this message

From: Charles C
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 02:00:05
Message: <web.44ceeccad4496aa83869c6770@news.povray.org>
CdeathJd,
If you haven't done so by now, do a search on these newsgroup for roller
coasters.  There are some that people have worked on already, albiet not
always directly in SDL.

Read up on using splines in the docs, they might be really useful. For a
pertinant example check out:
/scenes/animation/splinefollow/splinefollow.pov

Every so often I see discussion about how to interpolate equal lengths along
a spline without a lot of iteration.  If you do end up using splines, I want
to say it sure is handy if you choose control points that already happen to
be fairly evenly spaced.   Also, splines also give you a quick way to fake
physics by adjusting values or distances between control points.

Charles

PS, I'm still not sure this is what you want since it sounds like you have
working code for something else and might not want to start from scratch?


Post a reply to this message

From: CdeathJd
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 14:20:00
Message: <web.44cf9afcd4496aa8e2e0912a0@news.povray.org>
"Charles C" <nomail@nomail> wrote:
> CdeathJd,
> If you haven't done so by now, do a search on these newsgroup for roller
> coasters.  There are some that people have worked on already, albiet not
> always directly in SDL.
>
> Read up on using splines in the docs, they might be really useful. For a
> pertinant example check out:
> /scenes/animation/splinefollow/splinefollow.pov
>
> Every so often I see discussion about how to interpolate equal lengths along
> a spline without a lot of iteration.  If you do end up using splines, I want
> to say it sure is handy if you choose control points that already happen to
> be fairly evenly spaced.   Also, splines also give you a quick way to fake
> physics by adjusting values or distances between control points.
>
> Charles
>
> PS, I'm still not sure this is what you want since it sounds like you have
> working code for something else and might not want to start from scratch?

in essence its going to be like a small rollercoaster type ride that takes
the viewer from 1 place to another, i still dont have any clue how to
achieve
this in pov-ray, i think angles must come into it somewhere but i have no
idea how to make it work, because pov-ray doesn't move objects relative to
their rotation.

crappy ascii image example:
........................................................
........................................................
........................................................
........................................................
...................................#....................
..................................#.....................
.................................#......................
................................##......................
...............................#.#......................
............................##...#......................
...........................#.....#......................
.........................###.....#......................
......................##...#.....#......................
.......#####.#####.###.....#.....#......................
TRACK---#.....#.....#.....#.....#......................
.........#.....#.....#.....#.....#......................

It doesn't matter if the track pieces overlap (at this point), it doesn't
look like
i can do this in POV-RAY because it has weird rotation and maths i think.
Shame,
because it would have looked wonderfull with pov-rays graphics.

i thought i would probably need to move the next track piece, to the old
ones, then
rotate it, then move it "forward" from that position relative to its new
rotation, but as i've
said a lot, pov-ray cant move objects relative to their current rotation.

An example of me doing this in a program (looking very cr/p i must say) can
be found:
http://www.selfign.co.uk/JPP/JPP_RandomCoaster.exe

Any more tips? i do apreciate the help, even if its not helping me!


Post a reply to this message

From: Mike Sobers
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 15:00:01
Message: <web.44cfa486d4496aa8d5f7071c0@news.povray.org>
"CdeathJd" <nomail@nomail> wrote:
> i have no
> idea how to make it work, because pov-ray doesn't move objects relative to
> their rotation.
>
> i thought i would probably need to move the next track piece, to the old
> ones, then
> rotate it, then move it "forward" from that position relative to its new
> rotation, but as i've
> said a lot, pov-ray cant move objects relative to their current rotation.
>

Rather than complain that POV can't do something, why not try to understand
the problem better?  You want to work in a local reference frame instead of
a global one - fine, then just write a macro to move your track pieces
around:

///Begin code
camera {
   location <0, 0, -3>
   look_at <0,1, 0>
   }
light_source { <0,10, -10>
  color rgb <1,1,1>}

#declare track =
box{ <-0.2,0,-0.5>, <0.2,0.1,0.5>
  pigment {rgb <1,1,1>}
  }

#macro Move_Rotate_Relative (A, B, R)
  translate -A
  rotate R
  translate A+B
#end

#declare A = <-1,0,0>;
#declare B = <0.9,0.5,0>;
#declare R = <0,0,20>;
object {track translate A }
object {track translate A Move_Rotate_Relative(A,B,R)}
#declare A = A + B;
#declare B = <1,0.3,0>;
#declare R = R + <0,0,-10>;
object {track translate A Move_Rotate_Relative(A,B,R)}

//// End code

Each track is placed relative to the previous one, just update the current
track piece location, and give new position and rotation.

> Any more tips? i do apreciate the help, even if its not helping me!

Well, believe it or not, the previous suggestions are much simpler and
easier to implement than the technique you described (unless, of course,
you're trying to port some existing code over to POVray, in which case a
simple macro should do the trick). Don't be too quick to put down software
you don't fully understand, and people will be more likely to help you
solve your problem.

Mike


Post a reply to this message

From: CdeathJd
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 15:25:00
Message: <web.44cfa987d4496aa8e2e0912a0@news.povray.org>
"Mike Sobers" <sob### [at] mindspringcom> wrote:

> Each track is placed relative to the previous one, just update the current
> track piece location, and give new position and rotation.
>
> > Any more tips? i do apreciate the help, even if its not helping me!
>
> Well, believe it or not, the previous suggestions are much simpler and
> easier to implement than the technique you described (unless, of course,
> you're trying to port some existing code over to POVray, in which case a
> simple macro should do the trick). Don't be too quick to put down software
> you don't fully understand, and people will be more likely to help you
> solve your problem.
>
> Mike

Thanks for the example, i've not looked into macros, they look a bit like
function statements, but i dont understand the example i'm afraid. It looks
like A is the position of the first object and b, is how much the next moves
from it, i get the rotation, but how is the user supposed to know the
correct movement between the track pieces if there are hundreds of objects?

BTW i know the programs failures are my own failiures in the field of maths,
i am probably disabled in this area of programming because i never could
understand trigonometry. I did also initially try to port code over but it
didn't work, as the inbuild functions between programs are totally
different.


Post a reply to this message

From: CdeathJd
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 16:50:01
Message: <web.44cfbe57d4496aa8e2e0912a0@news.povray.org>
ok i've been playing around with the "splinefollow.pov" file, and its a good
example of what im trying to do. But after playing around with it, and
adding some 150 points of my own, i've hit a weird problem i don't
understand, after a certain amount of time, it stops adding "track" to the
scene, but the camera, keeps on flying down the track.

NOTE i am using the following animation variables in the master pov-ray INI
file:
initial_clock=0
final_clock=5
initial_frame=0
final_frame=180

the pov file contains this:


// Persistence Of Vision raytracer version 3.5 sample file.
// File: splinefollow.pov
// Desc: Spline demo animation that shows how to make an object or
//       the camera fly along a spline. This is a cyclic animation.
// Date: August 30 2001
// Auth: Rune S. Johansen

#include "math.inc"
#include "transforms.inc"

#declare FirstPerson = yes;

sky_sphere {
   pigment {
      planar poly_wave 2
      color_map {
         [0.0, color <0.2,0.5,1.0>]
         [1.0, color <0.8,0.9,1.0>]
      }
   }
}

light_source {< 1,2,-2>*1000, color 1.0}
light_source {<-1,2, 1>*1000, color 0.7 shadowless}

plane { // checkered plane
   y, -200
   pigment {checker color rgb 1.0, color rgb 0.9 scale 100}
}

// The spline that the aircracfts fly along
#declare MySpline =
spline {
   cubic_spline

-2, <-8,-1,99>,
-1, <-17,-1,194>,
0, <-25,-1,288>,
1, <-33,-1,383>,
2, <-50,0,476>,
3, <-83,4,565>,
4, <-133,10,646>,
5, <-196,20,716>,
6, <-271,32,773>,
7, <-353,46,817>,
8, <-438,58,858>,
9, <-529,58,886>,
10, <-622,45,899>,
11, <-714,22,907>,
12, <-803,-8,920>,
13, <-887,-47,941>,
14, <-965,-93,967>,
15, <-1037,-147,997>,
16, <-1102,-208,1031>,
17, <-1159,-276,1066>,
18, <-1212,-345,1102>,
19, <-1268,-413,1138>,
20, <-1326,-480,1174>,
21, <-1386,-544,1209>,
22, <-1449,-607,1243>,
23, <-1511,-676,1264>,
24, <-1568,-751,1270>,
25, <-1616,-833,1264>,
26, <-1659,-917,1254>,
27, <-1702,-1001,1243>,
28, <-1781,-1037,1216>,
29, <-1842,-987,1171>,
30, <-1845,-896,1173>,
31, <-1847,-847,1249>,
32, <-1867,-884,1330>,
33, <-1878,-970,1369>,
34, <-1889,-1057,1405>,
35, <-1899,-1144,1442>,
36, <-1906,-1232,1477>,
37, <-1906,-1322,1509>,
38, <-1901,-1413,1536>,
39, <-1894,-1505,1557>,
40, <-1884,-1598,1573>,
41, <-1875,-1691,1587>,
42, <-1863,-1782,1612>,
43, <-1853,-1868,1651>,
44, <-1851,-1948,1703>,
45, <-1860,-2018,1765>,
46, <-1885,-2079,1833>,
47, <-1926,-2129,1902>,
48, <-1983,-2173,1965>,
49, <-2047,-2223,2013>,
50, <-2116,-2280,2045>,
51, <-2186,-2342,2061>,
52, <-2251,-2411,2063>,
53, <-2311,-2484,2053>,
54, <-2361,-2562,2033>,
55, <-2404,-2641,2002>,
56, <-2447,-2719,1971>,
57, <-2497,-2798,1953>,
58, <-2550,-2877,1946>,
59, <-2602,-2956,1936>,
60, <-2648,-3034,1911>,
61, <-2690,-3113,1878>,
62, <-2736,-3192,1851>,
63, <-2788,-3270,1839>,
64, <-2841,-3349,1833>,
65, <-2891,-3428,1817>,
66, <-2935,-3506,1787>,
67, <-2978,-3585,1755>,
68, <-3027,-3664,1735>,
69, <-3079,-3743,1727>,
70, <-3132,-3821,1718>,
71, <-3180,-3900,1697>,
72, <-3231,-3977,1675>,
73, <-3293,-4047,1658>,
74, <-3363,-4110,1646>,
75, <-3441,-4164,1643>,
76, <-3522,-4212,1635>,
77, <-3606,-4251,1614>,
78, <-3689,-4280,1579>,
79, <-3769,-4299,1530>,
80, <-3841,-4308,1469>,
81, <-3904,-4307,1398>,
82, <-3963,-4301,1324>,
83, <-4017,-4292,1247>,
84, <-4061,-4273,1165>,
85, <-4095,-4246,1080>,
86, <-4118,-4210,996>,
87, <-4131,-4166,913>,
88, <-4134,-4114,833>,
89, <-4130,-4057,757>,
90, <-4131,-4006,678>,
91, <-4140,-3965,592>,
92, <-4158,-3934,504>,
93, <-4184,-3915,415>,
94, <-4220,-3907,328>,
95, <-4264,-3910,244>,
96, <-4314,-3925,165>,
97, <-4371,-3951,93>,
98, <-4428,-3979,22>,
99, <-4485,-4007,-48>,
100, <-4530,-4035,-126>,
101, <-4558,-4062,-212>,
102, <-4571,-4090,-302>,
103, <-4581,-4117,-393>,
104, <-4583,-4142,-485>,
105, <-4575,-4162,-577>,
106, <-4558,-4179,-669>,
107, <-4532,-4193,-759>,
108, <-4496,-4202,-846>,
109, <-4451,-4208,-930>,
110, <-4404,-4213,-1012>,
111, <-4347,-4215,-1088>,
112, <-4283,-4214,-1158>,
113, <-4218,-4213,-1228>,
114, <-4154,-4212,-1297>,
115, <-4089,-4211,-1367>,
116, <-4023,-4208,-1435>,
117, <-3948,-4191,-1491>,
118, <-3869,-4160,-1533>,
119, <-3790,-4116,-1559>,
120, <-3715,-4059,-1571>,
121, <-3649,-3991,-1571>,
122, <-3574,-3935,-1565>,
123, <-3491,-3962,-1543>,
124, <-3469,-4050,-1530>,
125, <-3490,-4119,-1585>,
126, <-3493,-4106,-1675>,
127, <-3489,-4023,-1713>,
128, <-3484,-3946,-1665>,
129, <-3444,-3945,-1584>,
130, <-3392,-4005,-1534>,
131, <-3339,-4068,-1485>,
132, <-3288,-4131,-1437>,
133, <-3242,-4200,-1391>,
134, <-3200,-4275,-1349>,
135, <-3164,-4354,-1311>,
136, <-3133,-4438,-1278>,
137, <-3109,-4525,-1250>,
138, <-3126,-4610,-1277>,
139, <-3148,-4631,-1362>,
140, <-3137,-4567,-1426>,
141, <-3150,-4478,-1413>,
142, <-3215,-4444,-1359>,
143, <-3269,-4496,-1308>,
144, <-3271,-4587,-1313>,
145, <-3264,-4647,-1385>,
146, <-3258,-4671,-1473>,
147, <-3239,-4611,-1539>,
148, <-3250,-4521,-1532>,
149, <-3327,-4483,-1505>,
150, <-3405,-4531,-1504>,
}

// First-person-view camera
// Follows the same path as the first aircraft
#if (FirstPerson=yes)
   camera {
      location 0
      look_at z
      translate <0,0.4,0.4>
      Spline_Trans (MySpline, clock*11, y, 0.5, 0.5)
   }
#end

// The yellow wire that shows the spline path.
union {
   #declare C = 0;
   #declare Cmax= 150;
   #while (C<=Cmax)
      #declare Value1 = C/Cmax*11;
      #declare Value2 = (C+1)/Cmax*11;
      #declare Point1 = -0.5*y+MySpline(Value1);
      #declare Point2 = -0.5*y+MySpline(Value2);
      //sphere {Point1, 0.1}
      cylinder {Point1, Point2, 0.5}
      #declare C = C+1;
   #end
   pigment {color <1,1,0>}
}

I am unable to understand the code fully as i dont know why the "track"
suddenly stops, but think this may have something to do with the maths
after "Value1=" and "Value2=" which i don't understand at all. Can anyone
help?

Also, in rendering, pov-ray takes a long time with the first few frames,
then goes very quickly (i'm using resolution 160x120 for quick results).
Can anyone explain why this is either.

Once again, thanks for any and all info that helps me on the long road to
understanding.


Post a reply to this message

From: Trevor G Quayle
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 18:06:44
Message: <44cfd074$1@news.povray.org>
> Thanks for the example, i've not looked into macros, they look a bit like
> function statements, but i dont understand the example i'm afraid. It 
> looks
> like A is the position of the first object and b, is how much the next 
> moves
> from it, i get the rotation, but how is the user supposed to know the
> correct movement between the track pieces if there are hundreds of 
> objects?

Macros are slightly different than function statements.  Basically anything 
that is inside the macro is essentially replaced inline with the code in 
place of the macro call at parse time.  They make doing repetitive things a 
lot easier.

If you posted some code that you tried to do (cleaned up of course) someone 
could probably see what you are doing wrong or what assumptions you are 
mistaken on and lead you in the right direction.

-tgq


Post a reply to this message

From: CdeathJd
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 18:20:00
Message: <web.44cfd28cd4496aa8e2e0912a0@news.povray.org>
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:

> If you posted some code that you tried to do (cleaned up of course) someone
> could probably see what you are doing wrong or what assumptions you are
> mistaken on and lead you in the right direction.
>
> -tgq

see above post, dated 1 Aug 2006 20:50:01


Post a reply to this message

From: CdeathJd
Subject: Re: Rollercoaster type maths (not possible in povray?)
Date: 1 Aug 2006 18:30:00
Message: <web.44cfd56ad4496aa8e2e0912a0@news.povray.org>
"CdeathJd" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
>
> > If you posted some code that you tried to do (cleaned up of course) someone
> > could probably see what you are doing wrong or what assumptions you are
> > mistaken on and lead you in the right direction.
> >
> > -tgq
>
> see above post, dated 1 Aug 2006 20:50:01

EDIT: Did some more investigating, it was the *11 value at the end, it was
some how scaling between the first 11 points only, i should have realised
this sooner really. Thanks for the help. Trial and error, helping hands and
experimentation have won through again!


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

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