gdalgorithms-list

Re: [Algorithms] Rotation Matrices

[<dav...@hu...>]

    Imagine rotating a cylinder in 3 dimensions about the 2 of the 3
principle axis.  This works best if you pick up a cylindrical medicine
bottle or something similiar (it helps to visualize).  Let's assume y is up,
x is left to right and z is towards and away from you.    Hold the cylinder
such that the "length" of the object points in the direction of y axis and
the "flat" section parallels the x axis.   Now perform these rotations:

a)
      - rotate 45 degrees around the y axis.  (you should notice the
cylinder just spins "in place", and does perceptually move if its a perfect
cylinder).
      - rotate 45 degrees about the x axis.  (it now leans toward or away
from you depending on the direction of rotation).

b)
      - rotate 45 degrees about the x axis. (it now leans toward or away
from you depending on the direction of rotation).
      - rotate 45 degrees around the y axis.  ( the cylinder now is at an
angle in more than one axis.)


As you can hopefully see, the order of rotations in 3 dimensions makes a
difference.


----- Original Message -----
From: <Nik...@ao...>
To: <gda...@li...>
Sent: Wednesday, August 02, 2000 1:25 PM
Subject: [Algorithms] Rotation Matrices


> Why isn't the multiplication of rotational matrices commutative?  For
example
> if I have one rotation matrix which rotates 20 degrees around the Z axis,
and
> another which rotates 50 degrees around the X axis, depending on the order
in
> which I multiply them, I get different results.  Why is this?  When
rotating
> an object there is no visible difference when it is first rotated on one
axis
> and then on another, is there?  I first looked in an elementary linear
> algebra book for the answer; however it stated that the multiplication of
> rotation matrices is commutative (although it was only covering 2D
rotation
> matrices). Any help would be appreciated.
>
> Thanks,
> Nik...@ao...
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] Rotation Matrices

[Ron L. <ro...@do...>]

Nik...@ao... wrote

> Why isn't the multiplication of rotational matrices commutative?

Because concatenation of rotations is not commutative.  In general,
concatenation of mappings is not commutative.

>For example
> if I have one rotation matrix which rotates 20 degrees around the Z axis,
and
> another which rotates 50 degrees around the X axis, depending on the order
in
> which I multiply them, I get different results.
>Why is this?  When rotating
> an object there is no visible difference when it is first rotated on one
axis
> and then on another, is there?

Wrong. Try a simple experiment to see for yourself.

Hold in your hand a rectangular box, whose three edges have different
lengths or are otherwise easily distinguishable.  Now rotate the box 90
degrees about the x -axis, then 90 degress about the y-axis.  Notice how it
is oriented.  Now return it to its original orientation and rotate first 90
degrees about the y-axis, then 90 degrees about the x-axis.  Notice that you
end up in a different final orientation.
That's the way the world is, in 3D anyway.  Rotations are not commutative.
If matrix multiplication were commutative then matrices would not be
suitable for representing rotations.

Concatenation of mappings in general is  not commutative, even 1-dimensional
mappings.  For example consider the 1-1 mapping of the line to itself given
by
x->x^3.  Now consider another 1-1 mapping of the line to itself given by
x->x+1.  Now concatenate them in two different orders.  In one case you get
x->(x+1)^3 in the other case you get
x->x^3+1.
As functions x^3 + 1 and (x +1)^3 = x^3 + 3x^2 + 3x + 1  are quite
different.  Concatenation of mappings, in general, is not commutative.

>I first looked in an elementary linear
> algebra book for the answer; however it stated that the multiplication of
> rotation matrices is commutative (although it was only covering 2D
rotation
> matrices). Any help would be appreciated.
>

It is true that concatenation of rotations about the origin in the plane is
indeed commutative.   That's just the way the world is.

RE: [Algorithms] Rotation Matrices

[Tom F. <to...@mu...>]

There is indeed a difference. Think of rotating an object 90 degrees about
the X, then 90 degrees about the Y. Now do it the other way. The object will
be pointing in completely different directions depending which way you do
it.

Only 2D rotations commute. 3D rotations don't.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Nik...@ao... [mailto:Nik...@ao...]
> Sent: 02 August 2000 19:25
> To: gda...@li...
> Subject: [Algorithms] Rotation Matrices
> 
> 
> Why isn't the multiplication of rotational matrices 
> commutative?  For example 
> if I have one rotation matrix which rotates 20 degrees around 
> the Z axis, and 
> another which rotates 50 degrees around the X axis, depending 
> on the order in 
> which I multiply them, I get different results.  Why is this? 
>  When rotating 
> an object there is no visible difference when it is first 
> rotated on one axis 
> and then on another, is there?  I first looked in an 
> elementary linear 
> algebra book for the answer; however it stated that the 
> multiplication of 
> rotation matrices is commutative (although it was only 
> covering 2D rotation 
> matrices). Any help would be appreciated.
> 
> Thanks,
> Nik...@ao...
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

[Algorithms] Rotation Matrices

[<Nik...@ao...>]

Why isn't the multiplication of rotational matrices commutative?  For example 
if I have one rotation matrix which rotates 20 degrees around the Z axis, and 
another which rotates 50 degrees around the X axis, depending on the order in 
which I multiply them, I get different results.  Why is this?  When rotating 
an object there is no visible difference when it is first rotated on one axis 
and then on another, is there?  I first looked in an elementary linear 
algebra book for the answer; however it stated that the multiplication of 
rotation matrices is commutative (although it was only covering 2D rotation 
matrices). Any help would be appreciated.

Thanks,
Nik...@ao...

RE: [Algorithms] FPS Questions

[Bass, G. T. <gt...@ut...>]

>To simulate motion blur, rather than average a few frames,
>shouldn't we have...

	How about having a rasterizer feature in hardware that can draw
lines instead of pixels?  Give it a motion vector for each object you're
drawing, and instead of rasterizing pixels, it will rasterize lines passing
through the actual pixel in screenspace, fading in alpha with distance from
the actual pixel location.

	This would make an excellent simulation of light reflection caught
on film from an object moving quickly in a straight line, though it wouldn't
look very good for spinning cubes and such.  I suppose you could provide a
velocity vector per vertex and interpolate the blur vectors on a per-pixel
basis.  With blazing fill-rate I think this could become feasible, and look
quite nice.

	Any IHV's up to the challenge? ;)

Regards,
Garett Bass
gt...@ut...

Re: [Algorithms] FPS Questions

[Thatcher U. <tu...@tu...>]

From: Robert Dibley <RD...@ac...>


> or it can display in non-interlaced mode, so the signal makes the scan
lines
> appear on top of each other, and you don't get the flicker.
>
> thats what most consoles do when not in hi res mode.

Yeah... I got acquainted with the intricacies of non-interlaced NTSC-like
video modes while working on the VR Bike & VR Climber, in which I had to
drive an arcade-style TV monitor from a regular VGA card.  Whereas a regular
NTSC frame has 525 horizontal lines for every two vertical syncs (i.e. 262.5
lines per field), the non-interlaced version drops the extra half-line, so
you have 262 lines per field.  Assuming a fixed horizontal scan rate, you
end up with a slightly higher vertical scan rate.  Directly connecting to a
monitor or a TV is no problem for such a tweaked mode, but it probably would
choke most pro video gear; for those kinds of applications we ran an
ordinary VGA signal through a scan-converter box.  If you diagram out the
timings you can see how it all fits together, and it becomes apparent what a
clever trick interlacing is.

Unfortunately, on larger monitors in non-interlaced modes the individual
scan lines can be excessively obvious.  I did a bunch of experimenting,
trying out modes with more horizontal lines, to combat this effect.  To get
more lines in a frame you have to speed up the horizontal sync or slow down
the vertical sync, which is all within the capabilities of a standard VGA
card.  There are tradeoffs naturally; with a slower vertical sync you have a
slower refresh and more obvious flicker, with a faster horizontal sync you
may have less horizontal resultion depending on how the video card timings
work out.  The big problem for me though was that while all monitors could
sync to a 262-line signal at ~60Hz refresh, they varied in how far
out-of-spec you could drive them before they completely lost sync.  I even
went as far as hacking up a circuit to induce interlace against the will of
the monitor by delaying the vsync signal on every other pulse, but that
didn't really work reliably.  Plus, interlaced modes look a little
"shimmery" to me, not as nice and solid as non-interlaced modes.  I ended up
sticking with the 262-line mode, and not worrying about the obvious scan
lines.

If you look at old arcade games you can see that many of them have similar
issues with scan lines.

Anyway, I don't think I have a point, but I couldn't resist the urge to talk
about the old days.

--
Thatcher Ulrich
http://tulrich.com

Re: [Algorithms] FPS Questions

[Stephen J B. <sj...@li...>]

On Wed, 2 Aug 2000, Stephen J Baker wrote:

> On Wed, 2 Aug 2000, gl wrote:
> 
> > > > executable) that perfectly demonstrate why accumlation buffer blur is
> > >
> > > you can use a accumulation buffer (or t buffer) to do proper motion
> > blur...
> > > there's nothing that prevents you from using it to do the averaging of the
> > > multiple frames for each displayed frame, and that's probibly the best way
> > > to go about it.
> > 
> > Good point.  But then of course you need to supersample the framerate.
> > Which brings us neatly back to why we need higher fps in the first place.
> 
> Well, strictly, you should still use motion blur even at 60Hz or higher
> because motion blur is really just *temporal* antialiasing.  The
> canonical example is that even on 60Hz systems, a rapidly spinning wheel
> will appear to slow down or run backwards when it revolves at speeds
> higher than 60Hz (or 60Hz divided by the rotational symmetry of the
              ^^^^^^^^^^^^^
          Ooops!  That should be 30Hz.
          *Half* the frame rate.

> wheel).  Motion blur is the way to fix that - and in theory, you always
> need it in any system that has a discreet 'frame rate'.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] FPS Questions

[Robert D. <RD...@ac...>]

or it can display in non-interlaced mode, so the signal makes the scan lines
appear on top of each other, and you don't get the flicker.

thats what most consoles do when not in hi res mode.

-----Original Message-----
From: Stephen J Baker [mailto:sj...@li...]
Sent: 02 August 2000 16:26
To: gda...@li...
Subject: Re: [Algorithms] FPS Questions


On Wed, 2 Aug 2000, Leath Muller wrote:

> > So what do console games do about interlace artifacts?  Are they
actually
> > running at half the vertical resolution of broadcast TV - or do they
have
> > fancy antialiasing filters to deal with it?
> 
> It's just in the HW to pass the image out to your TV... as far as the
> console is concerned, it's just a set resolution, say 320x240. The image
> is split at the HW just before the video cable and after the internal
> rasterization etc HW... Same as the ol' Amiga, Atari ST, etc...
 
Ah - that explains it.  Since TV's have ~480 scanlines (NTSC) - or
640 (PAL), the console must be repeating each scanline twice at 320x240,
so there is no interlace issue and it can effectively pretend to be
a 60Hz non-interlaced display.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FPS Questions

[Jim O. <j.o...@in...>]

> There's a fade in as well as a fade out. Motion blur is "forwards" as well
> as backwards. The exception to this is bright lights that "burn" the
retina
> (they don't really) - they don't have a fade-in, just a fade-out (as the
> retina cells recover). But they're special cases - most stuff fades in as
> well as out, so a straight summing of n rendered frames, each with
> timestamps distributed over period is the right thing to do.

If you say so...

Well, I am off to my well deserved vacation any minute now, so I am not very
eager to give it any more thoughts at this time - perhaps in a week or two,
when I'm back ;-).

Jim Offerman

Innovade
- designing the designer

Re: [Algorithms] FPS Questions

[Stephen J B. <sj...@li...>]

On Wed, 2 Aug 2000, gl wrote:

> > > executable) that perfectly demonstrate why accumlation buffer blur is
> >
> > you can use a accumulation buffer (or t buffer) to do proper motion
> blur...
> > there's nothing that prevents you from using it to do the averaging of the
> > multiple frames for each displayed frame, and that's probibly the best way
> > to go about it.
> 
> Good point.  But then of course you need to supersample the framerate.
> Which brings us neatly back to why we need higher fps in the first place.

Well, strictly, you should still use motion blur even at 60Hz or higher
because motion blur is really just *temporal* antialiasing.  The
canonical example is that even on 60Hz systems, a rapidly spinning wheel
will appear to slow down or run backwards when it revolves at speeds
higher than 60Hz (or 60Hz divided by the rotational symmetry of the
wheel).  Motion blur is the way to fix that - and in theory, you always
need it in any system that has a discreet 'frame rate'.

Unfortunately, doing *good* motion blur (not just averaging together
a bunch of static images - which doesn't really fix the temporal
antialiasing problem) is incredibly difficult - you really have
to render in four dimensions or something.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FPS Questions

[Stephen J B. <sj...@li...>]

On Wed, 2 Aug 2000, Leath Muller wrote:

> > So what do console games do about interlace artifacts?  Are they actually
> > running at half the vertical resolution of broadcast TV - or do they have
> > fancy antialiasing filters to deal with it?
> 
> It's just in the HW to pass the image out to your TV... as far as the
> console is concerned, it's just a set resolution, say 320x240. The image
> is split at the HW just before the video cable and after the internal
> rasterization etc HW... Same as the ol' Amiga, Atari ST, etc...
 
Ah - that explains it.  Since TV's have ~480 scanlines (NTSC) - or
640 (PAL), the console must be repeating each scanline twice at 320x240,
so there is no interlace issue and it can effectively pretend to be
a 60Hz non-interlaced display.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FPS Questions

[Conor S. <cs...@tp...>]

> Insane. But possibly just insane enough to actually work. Impressive.
> 
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
> 

Probably :) Thats the effect I like to go for. Mad professor.

Conor Stokes

RE: [Algorithms] FPS Questions

[Tom F. <to...@mu...>]

There's a fade in as well as a fade out. Motion blur is "forwards" as well
as backwards. The exception to this is bright lights that "burn" the retina
(they don't really) - they don't have a fade-in, just a fade-out (as the
retina cells recover). But they're special cases - most stuff fades in as
well as out, so a straight summing of n rendered frames, each with
timestamps distributed over period is the right thing to do.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Jim Offerman [mailto:j.o...@in...]
> Sent: 02 August 2000 08:18
> To: gda...@li...
> Subject: Re: [Algorithms] FPS Questions
> 
> 
> > you can use a accumulation buffer (or t buffer) to do proper motion
> blur...
> > there's nothing that prevents you from using it to do the 
> averaging of the
> > multiple frames for each displayed frame, and that's 
> probibly the best way
> > to go about it.
> 
> To simulate motion blur, rather than average a few frames, 
> shouldn't we have
> a function like:
> 
> P(1) = R(1) - C * P(0)
> 
> Where P(0) and P(1) are the color values of some pixel in the 
> (accumulation)
> buffer at t = 0 and t = 1 and R(1) is the color value for the 
> same pixel,
> resulting from the rendering of a frame at t = 1. C is a 
> constant, which
> controls the decay of light / the amount of motion blur.
> 
> Note that P(2) = R(2) - C * P(1) = R(2) - C * (R(1) - C * 
> P(0)) and so forth
> for P(3) to P(n).
> 
> Probably (and I am guessing here), C shouldn't be a constant 
> at all, but
> rather dependent on the velocity (both linear and radial) of 
> the viewer, as
> I think that motion blur increases with velocity.
> 
> Jim Offerman
> 
> Innovade
> - designing the designer
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] FPS Questions

[Tom F. <to...@mu...>]

Insane. But possibly just insane enough to actually work. Impressive.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Conor Stokes [mailto:cs...@tp...]
> Sent: 02 August 2000 05:02
> To: gda...@li...
> Subject: Re: [Algorithms] FPS Questions
> 
> 
> This is where I make evil confessions of things I've done :)
> 
>     Well, the main evil thing is actually using a form of AI system to
> calculate LoD levels on the fly to get a constant frame rate 
> in specific
> environments. A genetic algorithm which modified a neural 
> network style
> structure on the fly. The neural network style object used an kd-tree
> structure with output vectors stored at corner points of the 
> bounding hyper
> boxes.

[snip to avoid warping the mind]

> Mwhuhahahahaha.

Indeed.

> Conor Stokes

RE: [Algorithms] FPS Questions

[Tom F. <to...@mu...>]

> From: Stephen J Baker [mailto:sj...@li...]
 
[snip]
> So what do console games do about interlace artifacts?  Are 
> they actually
> running at half the vertical resolution of broadcast TV - or 
> do they have
> fancy antialiasing filters to deal with it?

The Dreamcast certainly has very good anti-flicker filter that seems to work
brilliantly - we didn't have to worry about horizontal white lines at all -
they just work. IIRC, the PS1 has none, and horizontal lines flicker badly.
I don't know about any of the other next-gen consoles, but I assume they
have some sort of filtering.

But it's only recently been a problem - most older consoles only ran at
320x240 anyway, so horizontal lines were on both fields, and didn't flicker
(nearly as much).

[snip]

> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

Re: [Algorithms] FPS Questions

[gl <gl...@nt...>]

> > executable) that perfectly demonstrate why accumlation buffer blur is
>
> you can use a accumulation buffer (or t buffer) to do proper motion
blur...
> there's nothing that prevents you from using it to do the averaging of the
> multiple frames for each displayed frame, and that's probibly the best way
> to go about it.

Good point.  But then of course you need to supersample the framerate.
Which brings us neatly back to why we need higher fps in the first place.
--
gl

RE: [Algorithms] Smooth movement of camera along a path

[Robert D. <RD...@ac...>]

Just a quick note to say that one way to solve the problem of orientations
is to not use them at all, but instead interpolate your "target" along with
your camera, so that you just build a camera that looks at the target ...
which you would then naturally avoid tilting.  Of course if you _want_
tilting cameras this is no use whatsoever !

Rob

-----Original Message-----
From: Peter Warden [mailto:Pet...@vi...]
Sent: 01 August 2000 12:40
To: gda...@li...
Subject: RE: [Algorithms] Smooth movement of camera along a path


I've done a couple of similar systems, and I've found the problem to be
deceptively tricky, a few things I ran across that weren't obvious to me
when I started;

-Whatever spline you pick to move the camera's position, you'll need to be
aware that changing the parameter to the spline isn't proportional to
distance along the spline, eg a u parameter of 0.5 may correspond to a point
that's only 0.25 of the total distance along the spline. This means that
some compensation will be needed if you want the camera to move at a
constant speed, or to accelerate and decelerate under your control. One
solution I used was to sample the spline at many points, and construct a
series of (very small) straight lines to represent the spline. This let me
do distance calculations and get smooth movement, at the cost of being a bit
inelegant. Advanced Animation and Rendering Techniques, Watt&Watt, 15.3.2
has a good discussion of this, and some other ways of solving the problem.

-Splines will solve the movement problem, but not necessarily the
orientation one. Interpolation between orientations is a big subject, and
took a lot more time than I expected!

-It's not just a maths problem, there's a lot of quirky human stuff that
needs to taken into account to get a camera moving in a way that people will
like. A good example of this is interpolating orientations, it's very easy
to end up with interpolated orientations that are tilted in uncomfortable
ways.

Having been a wet blanket with all this, I would say on the positive side
that adding extra keyframes so you aren't putting too much strain on the
interpolation code solves a lot of the problems, and most others can be
solved by working around them.

AA&RT, Watt and Watt, is an excellent source for info on the subject.

Peter Warden

> -----Original Message-----
> From: Mark Wilczynski [mailto:mwi...@cy...]
> Sent: Monday, July 31, 2000 11:04 PM
> To: gda...@li...
> Subject: [Algorithms] Smooth movement of camera along a path
> 
> 
> I'm trying to write a fly-by sequence (similar to the Unreal
> intro) for my 3d engine.  Can anyone tell me how to smoothly
> move the camera along a set of predefined 3d points?
> Ideally,  I would like a system where I manually move the
> camera around the environment and record keyframes at
> certain positions/orientations.  Then I would like the
> system to automatically move the camera along a path
> interpolated from these keyframes.  I'm guessing I need some
> sort of spline or other curve to do the job?
> 
> -Mark
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FPS Questions

[Jim O. <j.o...@in...>]

> you can use a accumulation buffer (or t buffer) to do proper motion
blur...
> there's nothing that prevents you from using it to do the averaging of the
> multiple frames for each displayed frame, and that's probibly the best way
> to go about it.

To simulate motion blur, rather than average a few frames, shouldn't we have
a function like:

P(1) = R(1) - C * P(0)

Where P(0) and P(1) are the color values of some pixel in the (accumulation)
buffer at t = 0 and t = 1 and R(1) is the color value for the same pixel,
resulting from the rendering of a frame at t = 1. C is a constant, which
controls the decay of light / the amount of motion blur.

Note that P(2) = R(2) - C * P(1) = R(2) - C * (R(1) - C * P(0)) and so forth
for P(3) to P(n).

Probably (and I am guessing here), C shouldn't be a constant at all, but
rather dependent on the velocity (both linear and radial) of the viewer, as
I think that motion blur increases with velocity.

Jim Offerman

Innovade
- designing the designer

RE: [Algorithms] Smooth movement of camera along a path

[Peter W. <Pet...@vi...>]

I've done a couple of similar systems, and I've found the problem to be
deceptively tricky, a few things I ran across that weren't obvious to me
when I started;

-Whatever spline you pick to move the camera's position, you'll need to be
aware that changing the parameter to the spline isn't proportional to
distance along the spline, eg a u parameter of 0.5 may correspond to a point
that's only 0.25 of the total distance along the spline. This means that
some compensation will be needed if you want the camera to move at a
constant speed, or to accelerate and decelerate under your control. One
solution I used was to sample the spline at many points, and construct a
series of (very small) straight lines to represent the spline. This let me
do distance calculations and get smooth movement, at the cost of being a bit
inelegant. Advanced Animation and Rendering Techniques, Watt&Watt, 15.3.2
has a good discussion of this, and some other ways of solving the problem.

-Splines will solve the movement problem, but not necessarily the
orientation one. Interpolation between orientations is a big subject, and
took a lot more time than I expected!

-It's not just a maths problem, there's a lot of quirky human stuff that
needs to taken into account to get a camera moving in a way that people will
like. A good example of this is interpolating orientations, it's very easy
to end up with interpolated orientations that are tilted in uncomfortable
ways.

Having been a wet blanket with all this, I would say on the positive side
that adding extra keyframes so you aren't putting too much strain on the
interpolation code solves a lot of the problems, and most others can be
solved by working around them.

AA&RT, Watt and Watt, is an excellent source for info on the subject.

Peter Warden

> -----Original Message-----
> From: Mark Wilczynski [mailto:mwi...@cy...]
> Sent: Monday, July 31, 2000 11:04 PM
> To: gda...@li...
> Subject: [Algorithms] Smooth movement of camera along a path
> 
> 
> I'm trying to write a fly-by sequence (similar to the Unreal
> intro) for my 3d engine.  Can anyone tell me how to smoothly
> move the camera along a set of predefined 3d points?
> Ideally,  I would like a system where I manually move the
> camera around the environment and record keyframes at
> certain positions/orientations.  Then I would like the
> system to automatically move the camera along a path
> interpolated from these keyframes.  I'm guessing I need some
> sort of spline or other curve to do the job?
> 
> -Mark
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] FPS Questions

[Conor S. <cs...@tp...>]

This is where I make evil confessions of things I've done :)

    Well, the main evil thing is actually using a form of AI system to
calculate LoD levels on the fly to get a constant frame rate in specific
environments. A genetic algorithm which modified a neural network style
structure on the fly. The neural network style object used an kd-tree
structure with output vectors stored at corner points of the bounding hyper
boxes.

    The current input vector was pushed down the tree until it found the
node, and linear interpolation between the closest output values was used.
If the frame speed was outside a error metric, then a modifier was used. The
modifiers were genetically terminated also. If a modifier didn't fix a
problem, it was modified as well. The system worked quite well. The kd-tree
structure allowed additional non linear information to be accounted for.
Twas a rather evil thing to do. Maybe one day I'll do a demo.

    The output vectors simply allowed me to map LoD to priorities (eg, the
camera distance) and complexity (eg, how long one LoD element takes) to
output a fairly reasonable estimate in most circumstances.

    I don't know why I feel I need to voice this here and now, but I do :)
And I will probably be laughed at for the sheer insanity of the idea ;)

Mwhuhahahahaha.

Conor Stokes

> As for finding the optimum details settings to get "n"Hz on a machine,
with
> continuous LoD methods, you can get quite close (+/- 5Hz is not too hard
to
> achieve 95% of the time). You have some sensible defaults for rendering
> quality (i.e. how many passes), according to card type, allow the user to
> override them if they feel like it, and then CLOD up or down to get the
> right frame rate (within sane limits).
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.

Re: [Algorithms] FPS Questions

[<Lea...@en...>]

> So what do console games do about interlace artifacts?  Are they actually
> running at half the vertical resolution of broadcast TV - or do they have
> fancy antialiasing filters to deal with it?

It's just in the HW to pass the image out to your TV... as far as the
console is concerned, it's just a set resolution, say 320x240. The image
is split at the HW just before the video cable and after the internal
rasterization etc HW... Same as the ol' Amiga, Atari ST, etc...

Leathal.

Re: [Algorithms] FPS Questions

[jason w. <jas...@po...>]

> executable) that perfectly demonstrate why accumlation buffer blur is

you can use a accumulation buffer (or t buffer) to do proper motion blur...
there's nothing that prevents you from using it to do the averaging of the
multiple frames for each displayed frame, and that's probibly the best way
to go about it.

you do see a lot of people implimenting simple previous frame blurrs..
basicly, because it's cheap :)

Re: [Algorithms] FPS Questions

[Stephen J B. <sj...@li...>]

On Tue, 1 Aug 2000, Keith Z.Leonard wrote:

> Actually, if we are going to be nit-picky the ~60hz of TV is interlaced, so
> you are seeing half-frames, with an actual "frame" rate of 29.97hz

Well, each scanline is painted ~30 times a second - but it draws all the odd
numbers lines in one 1/60th second period and all the even numbered scanlines
on the next 1/60th second.  Hence you see changes in the position of objects
60 times a second - so double imaging shouldn't happen as it would in a true
30Hz setup.

...and for some countries, it's 25Hz and 50Hz rather than 30 and 60
as it is here in USA.

What you get with TV is interlace flicker where one pixel high lines only
show up every alternate field - 30Hz.  Fortunately TV cameras and TV
graphics systems know about this and are very careful to deal with it.

There are also some very peculiar psycho-physical effects when an object
is moving vertically up or down the screen at more or less exactly one
scanline per field - this is called 'entrainment' - and I don't understand
it.  It makes some people very ill and other people mis-judge the speed
of things.

So what do console games do about interlace artifacts?  Are they actually
running at half the vertical resolution of broadcast TV - or do they have
fancy antialiasing filters to deal with it?

> Are movies also interlaced??

No - you can't interlace a film - it doesn't have raster structure.

> I thought that I read somewhere that movies had moved to a 48 hz refresh.

So we are reliably informed (I didn't know that before) - they display the
same entire image twice though - similar to PC's running at 30Hz.

> Also, none of this really matters to computer frame rate discussion,
> the end result is that people can see the difference between 30 and
> 60 fps, and the change is significant. 

For fast-moving images - yes.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] FPS Questions

[Stephen J B. <sj...@li...>]

On Tue, 1 Aug 2000, Tom Forsyth wrote:

> I like the theory - shame move theaters show each image twice really,
> otherwise it'd be a really good one.

Yes - I didn't know they did that - but if you see double imaging
in movies - then I'm still right about the 30/60Hz issues in games
which is what matters.

> Though to be fair I see double images
> when movies pan (really bad flickery double images too - ugh) - so your
> theory still holds.
 
Yes - I guess I've never noticed the double imaging in movies because

a) Even 48Hz stinks.
b) Excessive motion blur to compensate for 48Hz stinks too.

> "it evolved to throw rocks at rabbits running behind trees." How true. How
> Quake :-)

  :-)

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FPS Questions

[gl <gl...@nt...>]

> I'm surprised no one has mentioned thus far the most significant
> difference between movie frames and real-time gfx frames.  I know I drag
you
> all through this each time this discussion comes up, but I'll rehash once
> more.

Erm, <cough>.

Incidentally, here's an excellent motion blur description (and demo
executable) that perfectly demonstrate why accumlation buffer blur is
nothing to do with real motion blur (ie. it doesn't contain any extra
information, unlike true motion blur):

http://freespace.virgin.net/hugo.elias/graphics/x_motion.htm
--
gl