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<si...@popcornfilms.com> 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 do a stepwise transform on an object - you regenerate the matrix > from scratch each time. (This is one of those things you never really see in > practice; most engines split out the rotational transforms and keep them > separate, using either an axis-angle representation, quaternions, or in some > bad cases, euler angles [this is what Unreal uses btw]. That way, you keep > fidelity - or at the very least, you don't care too much about inaccuracies > as they come in - you can just ignore them if your object is rotated a > little off; it's not a culumlative error). > > Assuming no scaling or shear, just rotation and translation, your > translation is the rightmost column of numbers in the matrix. If all of your > objects are pre-scaled in memory to the right size, all you have to do is > apply the rotation and translation in order to each of the points. > Screen-space projection is a little more difficult, but that one you can > precalc all the divides in. > > On machines without SIMD or dedicated 3D instructions (such as the SAM), > it's nearly always best to break out the matrix into individual linear > equations, take the common pieces and only calculate them once, and then > operate on them that way. > > -- > Simon Cooke > Director of Engineering / Business Developer, X-RAY KID STUDIOS - > www.x-raykid.com > Founder, Popcorn Films - www.popcornfilms.com > Cell: 206 250 7892 XBOX Live GamerTag: Spec Tec > > -----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 5:14 AM > To: sam-users@nvg.ntnu.no > Subject: Re: Hi - just checking > > That's not entirely true. Matrices are numerically unstable, so the > cost of ensuring they remain orthonormal when applying consecutive > local transforms in a game such as Elite is substantially greater than > the cost of ensuring that a quaternion remains of unit length. > > I make it 8 multiplies, 3 adds, 1 square root and 1 divide to fix up > numerical error in a quaternion. Conversely, I get 36 multiplies, 21 > adds, 3 square roots and 3 divides to fix up an orthonormal matrix. > > Quaternion to matrix is 10 multiplies, 6 shifts and 14 adds. So the > way I calculate it, you can fix a quaternion and convert it into a > matrix in less than you can fix up a matrix. Furthermore, quaternion > composition is 16 multiplies and 12 adds, whereas matrix composition > (with assumptions about the bottom row of a 4x4) is, ummm, at least 36 > multiplies and 18 adds. And that's with the translation component not > completely factored in (I'm reading actual code off screen and have > optimised the translation out of this particular batch). > > Elite is also a perfect example of when Euler's aren't fine, even if > they didn't produce Gimbal lock, as all rotation is around local axes. > And besides that, Euler angles always have to be converted to some > other form before they can be applied to arbitrary geometry. Matrices > require no further transforms. > > On Wed, Aug 5, 2009 at 2:12 AM, Simon Cooke<si...@popcornfilms.com> wrote: >> You only really need quaternions if you're doing animation or > interpolation. >> If you can live with the gimble lock, euler's fine. >> >> -----Original Message----- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Thomas Harte >> Sent: Tuesday, August 04, 2009 10:05 AM >> To: sam-users@nvg.ntnu.no >> Subject: Re: Hi - just checking >> >> Am I replying to the correct thread? I don't know. But I've had the >> opposite experience to a bunch of people here, having become >> substantially more busy in my work than I was even just a few months >> ago, squeezing the SAM temporarily out. >> >> A version of my vector 3d-stuff-as-a-library-for-others was all but >> finished several months ago, I'll endeavour to get that out, though it >> still has the awkward limitation of doing rotations with Euler angles >> only - which may be less efficient and is certainly more limiting than >> special orthogonals or quaternions. >> >> I'm still thinking about smart ways to optimise the reverse face >> stuff. I need to get something hierarchical or otherwise group-related >> in there; checking every single face is obviously not the optimal way >> to proceed. I guess what I'm looking for is some sort of bin-type >> mapping to the surface of the unit sphere that allows all the points >> on a particular hemisphere to be isolated from the majority of the >> points on the opposite hemisphere. Or, you know, something at least a >> lot like a sphere. Though I'm not sure any sort of lookup into >> something a lot like a sphere would help much as it'd need to be >> indexed by a three-tuple. >> >> I guess a good broad sweep would be to mark each face according to the >> visibility of the faces of a bounding box - if a face on the real >> model points away from the face on the bounding box then it definitely >> can't be visible if the box face is. Or something like that. >> >> I'm going to stop thinking aloud now... >> >> On Tue, Aug 4, 2009 at 10:22 AM, Steve Parry-Thomas<morriga...@aol.com> >> wrote: >>> I guess when the clocks go back in October SAM users will hibernate over >> the >>> winter until next August! >>> >>> >>> >>> >>> >>> >>> >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Ian Spencer >>> Sent: 04 August 2009 08:04 >>> >>> To: sam-users@nvg.ntnu.no >>> Subject: Re: Hi - just checking >>> >>> >>> >>> Wow, I just sent the checking mail to see whether something was wrong > with >>> my subscription to the group and it seems it was like poking a stick into >> a >>> hornets nest (in a positive sort of way) - over 40 mails in the last few >>> days on the group. It's just great to see everyone is alive and kicking >> out >>> there. >>> >>> >>> >>> Ian >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: Ian Spencer >>> >>> To: sam-users@nvg.ntnu.no >>> >>> Sent: Friday, July 31, 2009 4:10 PM >>> >>> Subject: Hi - just checking >>> >>> >>> >>> Not heard anything on the group for quite a while so just thought I would >>> send a 'test' to check it's not me that's got a problem and say hi to >>> everyone. >>> >>> I know you've all taken your Sam's to the beach and so no activity on the >>> group. >>> >>> >>> >>> >>> >>> Ian >>> >>> >>> >>> >> >> > >
