It's still pretty much just a quick sin/cos lookup for the euler angle
calculation. As you say, you just store it in a form that hits 0 at 0, and
2pi - epsilon at 65535. (Or something similar), and then just do a lookup.
That part's fast.
Quaternions... The biggest advantage is that you can interpolate between
them - which is necessary for skeletal animation. There are a number of
disadvantages though - the need to occasionally renormalize them being a big
one. (You're not actually gaining any kind of stability there per se; all
you're doing is trading one numerical inaccuracy for another).
Here's a case against them:
http://www.gamedev.net/reference/articles/article1199.asp
http://www.somedude.net/gamemonkey/forum/viewtopic.php?f=12&t=380
http://www.sjbrown.co.uk/2002/05/01/quaternions/
Note: it may make sense to handle your camera as a quaternion, vs. a
rotation matrix for local->worldspace transforms, based on the cost of
operations.
If you decompose your matrix into all of the pieces you need to calculate
when you build it, and keep that alongside all of the pieces you need to
apply when you apply it, then you might find more optimization opportunities
- especially if you're not performing more than one rotation at once.
But ultimately, the name of the game here is to go as far as possible, so
it's all going to come down to your use cases.
-Original Message-
From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On
Behalf Of Thomas Harte
Sent: Wednesday, August 05, 2009 4:13 PM
To: sam-users@nvg.ntnu.no
Subject: Re: Hi - just checking
They're in some format or another that I don't recall offhand, but is
lined up so that a full circle is a nice round binary number for the
obvious range fixing optimisation. But it's not just a quick sin/cos
table lookup unless you're rotating around one axis only. See, e.g.
http://www.manpagez.com/man/3/glRotatef/ (the man page for glRotatef)
- clearly there's a lot more going on there than table lookups.
Of course, I am taking note of coherences. If the angles associated
with an object do not change from one frame to the next, the source
matrix is not recalculated. This optimisation postdates the version of
my code that has already appeared on Sam Revival, but predates the
next version (which is a better optimised version of the code shown in
my video http://www.youtube.com/watch?v=j0xN_Mi3B_I)
As I've posted to this list in the past, I use something vaguely like
SIMD to multiply a 2d vector by a scalar - the relevant part of the
scalar sits in the accumulator and is shifted there to make the
add/don't add decision in the standard binary multiplication formula,
meanwhile the 2d vector sits with the work going in for one component
occupying BC, DE and HL, the work for the other occupying BC', DE' and
HL'. Hence I get a substantial saving on multiplying the two vector
components by the scalar separately.
Naturally, I have a classic y = f((x^2)/4) table for the limited range
multiplications (related to the maximum size an individual object may
be).
I assume your point about not accumulating transformations in matrices
effectively means that you agree that quaternions are useful beyond
interpolation and animation (which I'm interpreting quite narrowly to
be the traditional skeletal type, not broadly to be any old moving
image).
Anyway, hopefully I'll be able to get myself in gear for a source
release at some point in the near future, then you can rip it apart.
It's all geared up to be trivial for other (assembler) coders to use
to produce their own programs, handling triple buffering and frame
rate compensation with very limited need for work on the part of the
programmer (which neatly means that all my code scales really well
from a normal Sam to a Mayhem or otherwise accelerated machine), etc.
I tidied most of it up for a release quite a while ago but decided to
switch to Jam rather than sticking on pyz80 because a lot of stuff
would be substantially more compact and more readable with proper
macro support. I also would much rather that the demo was seen first
on Sam Revival rather than on the internet, both as a pathetic attempt
to support the publication and because it looks much better on a real
television. Never found time to convert it though, so it'll be a pyz80
release.
Actually, the demo on the previous Sam Revival was explicitly flagged
as PD, so I'll upload a DSK of that demo somewhere once the next
edition is out. I think I mentioned every Sam program I've written in
the SR article; you can see most of them very briefly in
http://www.youtube.com/watch?v=kr_Lz98qVjE&feature=channel_page
On Wed, Aug 5, 2009 at 10:16 PM, Simon Cooke wrote:
> Hmmm... what form are you using your Eulers in? If it's radians, it's not
> too bad - just a quick sin/cos table lookup. And you only need to do it
once
> per object if it's a simple rigid body.
>
> The trick with making matrices numerically stable is that you don't ever
> want to d
