 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm new to ng posting, so let me know if i screw something up. :)
Long background description of the project. If interested read it :)
otherwise I have a math question at the bottom.
I've been working on a system for scripting car-motion. It's
geometry-based. ... Based on the idea that when turning, the car will
revolve around some point which is located at the intersection of where the
normals (if extended) of all four wheels interrsect. Each wheel is then
tangent to the overall axis of rotation and... tracks along the ground
rather than skids. That point of course always be inline with the back
axle.
The steering angle of the car is defined by an imaginary middle front wheel.
If it is say... 45 degrees left, the angle of the left and right front
wheels are calculated separately. The wheel on the inside of the turn will
be something steeper than 45 and vice versa for the wheel on the outside of
the turn.
This approach is very geometry based... as opposed to an approach involving
a simple physics model. (I know of at least one commercial package for
animators which models forces and is specifically for people who want to
animate vehicles.) But that's what I intended it to be. I was shooting
for something backed by nice clean math.... (...in theory....however pretty
or ugly the the actual code looks is another story. :) So far so good.
I wanted accelleration and smooth steering-angle change. So I worked on a
simple scripting system where you can tell it initial speed, speed delta,
initial steering angle and steering delta. ...And how long to do it. Any
time one of the variables changes, it defines a new motion segment.
Realistic car motion can (well hopefully) be created by stringing together a
sequence of segments.
The problem is in the iterative approach calculating each segment. I use
macros to move the car through many small movements for different steering
angles if the steering delta is non-zero. (The final position of the car
is easy to calculate in one step as long as the steering angle for the
segment is constant.) When an animation involves a long list of motion
segments, recalculating the movement of the car from the beginning for each
frame puts a real parsing burdon on my almost antique computers. :)
So now I have a system that pre-processes all of the motion segments and
saves the results in a file. For each frame only one motion segment (or
partial motion segment) will need to be calculated. This works great for
final rendering but I still need to work on a generalized system for when
I'm doing test renders. (I.e. one that can separately remember individual
segments rather than pre-calculating The Whole Thing.)
************************************************************************
In the spirit of clean mathematical models, I really want to do each motion
segment in one step using calculus.
I figured there are seven integrals I need to find:
*The first one gives the cumulative of the rate of change of the direction
the car is facing... and thus gives the final direction the car is facing
for the given segment.
*The second and third integrals find the x and y locations of the car. For
the x position, take the cosine (or sine for y position) of the first
integral, multiply it by the current speed as speed changes. Take the
integral of this (in terms of time of course).
*The other four integrals are of the speeds of each of the wheels. Knowing
how far each wheel has travelled we know how many times each wheel has
turned.
The first integral is do-able. The second and third might not be. (4,5,6
&7 I haven't bothered with yet... at least they're not all completely
different....) I'm having trouble integrating anything with a trig
function within a trig function... Say the integral of:
cos( sin(x) ) dx
Seems like everything I try leads me in circles.
If it were something like:
cos( sin(x) ) * cos(x) dx
it would be easy with substitution.... but unfortunately... :)
I've been looking for a way I can simplify the actual problem so that the
trig-within a trig function goes away... or something...
If mathematica can't do it, is that a bad sign? I threw a few things into
the online mathematica integrator. http://integrals.wolfram.com/
Unfortunately it wasn't able to do them.
Help? Suggestions? Is there a way to approximate these integrals w/o
iteration?
-Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 20 Jan 2009 04:50:08 -0800, cc wrote:
>I've been working on a system for scripting car-motion. It's
>geometry-based. ... Based on the idea that when turning, the car will
>revolve around some point which is located at the intersection of where the
>normals (if extended) of all four wheels interrsect. Each wheel is then
>tangent to the overall axis of rotation and... tracks along the ground
>rather than skids. That point of course always be inline with the back
>axle.
I haven't looked at the whole thing yet, but I can tell you that this
part at least is incorrect. If the front wheels are parallel, their
axes will never intersect. In fact when you turn, one or both wheels
will skid just a little.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 20 Jan 2009 04:50:08 -0800, cc wrote:
>In the spirit of clean mathematical models, I really want to do each motion
>segment in one step using calculus.
>
>I figured there are seven integrals I need to find:
>
>*The first one gives the cumulative of the rate of change of the direction
>the car is facing... and thus gives the final direction the car is facing
>for the given segment.
>
>*The second and third integrals find the x and y locations of the car. For
>the x position, take the cosine (or sine for y position) of the first
>integral, multiply it by the current speed as speed changes. Take the
>integral of this (in terms of time of course).
>
>*The other four integrals are of the speeds of each of the wheels. Knowing
>how far each wheel has travelled we know how many times each wheel has
>turned.
I'm not convinced that you need integrals. The lengths of circular arcs
are trivially calculated without integrals; simply multiply the radius of
the arc by the angle in radians. Each wheel will follow a circular arc,
so you just need to add them up. This covers "the other four."
The second and third aren't as hard as you're making them, either. The
easiest way to do what you want is to use POV's vaxis_rotate function,
which takes an initial position and rotates it around a given center by
a given angle, returning the final position.
The first one is probably the easiest: you just add up all of the angles
and the result is the change in direction.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roads and railways use 'transition' curves... a curve based on a
continuously variable radius throughout the turn. That is why you slowly
increase and decrease the steering wheel offset while driving. A fixed
radius curve would require a sudden change in road wheel and steering wheel
angle.
cc <coy### [at] fojar com> wrote in message news:388702d1@news.povray.org...
> I'm new to ng posting, so let me know if i screw something up. :)
>
> Long background description of the project. If interested read it :)
> otherwise I have a math question at the bottom.
>
> I've been working on a system for scripting car-motion. It's
> geometry-based. ... Based on the idea that when turning, the car will
> revolve around some point which is located at the intersection of where
the
> normals (if extended) of all four wheels interrsect. Each wheel is then
> tangent to the overall axis of rotation and... tracks along the ground
> rather than skids. That point of course always be inline with the back
> axle.
>
> The steering angle of the car is defined by an imaginary middle front
wheel.
> If it is say... 45 degrees left, the angle of the left and right front
> wheels are calculated separately. The wheel on the inside of the turn
will
> be something steeper than 45 and vice versa for the wheel on the outside
of
> the turn.
>
> This approach is very geometry based... as opposed to an approach
involving
> a simple physics model. (I know of at least one commercial package for
> animators which models forces and is specifically for people who want to
> animate vehicles.) But that's what I intended it to be. I was shooting
> for something backed by nice clean math.... (...in theory....however
pretty
> or ugly the the actual code looks is another story. :) So far so good.
>
> I wanted accelleration and smooth steering-angle change. So I worked on
a
> simple scripting system where you can tell it initial speed, speed delta,
> initial steering angle and steering delta. ...And how long to do it.
Any
> time one of the variables changes, it defines a new motion segment.
> Realistic car motion can (well hopefully) be created by stringing together
a
> sequence of segments.
>
> The problem is in the iterative approach calculating each segment. I use
> macros to move the car through many small movements for different steering
> angles if the steering delta is non-zero. (The final position of the car
> is easy to calculate in one step as long as the steering angle for the
> segment is constant.) When an animation involves a long list of motion
> segments, recalculating the movement of the car from the beginning for
each
> frame puts a real parsing burdon on my almost antique computers. :)
>
> So now I have a system that pre-processes all of the motion segments and
> saves the results in a file. For each frame only one motion segment (or
> partial motion segment) will need to be calculated. This works great for
> final rendering but I still need to work on a generalized system for when
> I'm doing test renders. (I.e. one that can separately remember individual
> segments rather than pre-calculating The Whole Thing.)
>
> ************************************************************************
>
> In the spirit of clean mathematical models, I really want to do each
motion
> segment in one step using calculus.
>
> I figured there are seven integrals I need to find:
>
> *The first one gives the cumulative of the rate of change of the direction
> the car is facing... and thus gives the final direction the car is facing
> for the given segment.
>
> *The second and third integrals find the x and y locations of the car.
For
> the x position, take the cosine (or sine for y position) of the first
> integral, multiply it by the current speed as speed changes. Take the
> integral of this (in terms of time of course).
>
> *The other four integrals are of the speeds of each of the wheels.
Knowing
> how far each wheel has travelled we know how many times each wheel has
> turned.
>
>
>
> The first integral is do-able. The second and third might not be.
(4,5,6
> &7 I haven't bothered with yet... at least they're not all completely
> different....) I'm having trouble integrating anything with a trig
> function within a trig function... Say the integral of:
> cos( sin(x) ) dx
> Seems like everything I try leads me in circles.
> If it were something like:
> cos( sin(x) ) * cos(x) dx
> it would be easy with substitution.... but unfortunately... :)
>
> I've been looking for a way I can simplify the actual problem so that the
> trig-within a trig function goes away... or something...
>
> If mathematica can't do it, is that a bad sign? I threw a few things into
> the online mathematica integrator. http://integrals.wolfram.com/
> Unfortunately it wasn't able to do them.
>
> Help? Suggestions? Is there a way to approximate these integrals w/o
> iteration?
>
> -Charles
>
>
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
cc wrote:
> I wanted accelleration and smooth steering-angle change. So I worked on a
If all you want is a nice movie, why not start with the given
shape of the curve and the location as a function of time,
and then get the angles etc. by differentiation?
> cos( sin(x) ) dx
Looks like something with a Bessel function to me. Are you sure
you want to use this?
If yes, try Gradstein/Ryshik or Abramowitz/Stegun (the first one
is a great collection of integrals ant other stuff, the second
has mostly definitions, but has all of them correct (it is
something like an ANSI standard about higher functions)).
Yet another way to do it would be to integrate numerically -- just
hack a Runge-Kutta using POV's macros.
Ralf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I haven't looked at the whole thing yet, but I can tell you that this
> part at least is incorrect. If the front wheels are parallel, their
> axes will never intersect. In fact when you turn, one or both wheels
> will skid just a little.
That is why cars use trapezoidal steering mechanisms.
--
Homepage: http://www.faricy.net/~davidf/
___ ______________________________
| \ |_ <dav### [at] faricynet>
|_/avid |ontaine <ICQ 55354965>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am just wondering, what exactly does integration do? Several people have tried
unsuccessfully to explain it to me. I believe something to do with area under a
curve? Just tell me what the input represents and what the output represents,
that's all I really want to know.
--
Homepage: http://www.faricy.net/~davidf/
___ ______________________________
| \ |_ <dav### [at] faricynet>
|_/avid |ontaine <ICQ 55354965>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricynet> wrote in message
news:3887B189.DE2796FE@faricy.net...
> I am just wondering, what exactly does integration do? Several people have
tried
> unsuccessfully to explain it to me. I believe something to do with area
under a
> curve? Just tell me what the input represents and what the output
represents,
> that's all I really want to know.
input: a bunch of things to be added up, with a certain weight for each.
An example is the average. You add up all of them but weight
them by 1/(number of things). average of a, b, and c is
a/3 +b/3+c/3.
Usually the term 'integration' is used when the things to
be added for a continuum of values. Thats why integration is
considered 'calculus'.
Say you want to know how a planet is going to revolve around its sun.
The force of gravity on the planet is not usually constant because the
planet
can go from one distance from its sun to other distances. To find out where
it will be tomorrow, you could 'move' it (on paper) in little increments
calculating the forces on it anew for each second, using its new position
and new forces. You are actually adding up all these effects, second
after second. But since it is more accurate to consider time as a
continuum, you really should add up a continuum of miniscule
effects. That is, you 'integrate' the effects
output: the sum
oh yeah, 'the area under the curve' explanation comes from finding the
area under a curve by adding up a bunch of rectangular regions (for
which you know that area=length X width) areas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I haven't looked at the whole thing yet, but I can tell you that this
>part at least is incorrect. If the front wheels are parallel, their
>axes will never intersect. In fact when you turn, one or both wheels
>will skid just a little.
>
>--
I used to have a radio controlled car which would turn the inside-wheel more
than the outside wheel. Whether it did it perfectly is another story... I
haven't done anything on my own to find out if real cars are that way too
but I hope that they are...
-Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't know what trapezoidal steering mechanisms do... Do they do what I
was talking about... about rotating the wheel on the inside of the turn at a
steeper angle than the wheel on the outside?
-Charles
David Fontaine wrote in message <3887B0B0.FCC0429F@faricy.net>...
>> I haven't looked at the whole thing yet, but I can tell you that this
>> part at least is incorrect. If the front wheels are parallel, their
>> axes will never intersect. In fact when you turn, one or both wheels
>> will skid just a little.
>
>That is why cars use trapezoidal steering mechanisms.
>
>--
>Homepage: http://www.faricy.net/~davidf/
>___ ______________________________
> | \ |_ <dav### [at] faricynet>
> |_/avid |ontaine <ICQ 55354965>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
