RE: [GD-Consoles] transforms

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

> From: R & D (GameBrains) [mailto:res...@ga...]
> 
> Hello,
> Been quiet here for so long, thought I would post a question 
> :-)  We are redesigning our object manager and I was 
> wondering how others are handling their object 
> transformations on modern hardware, especially machines with 
> hardware T&L.
> 
> Overall, it seems to me that there has been a lot of research 
> on graphics algorithms, but not on scene graph management for 
> modern hardware. 

Personally, I think the hole notion of a unified "scene graph" is silly.
Different objects require different methods. Don't try to unify a portal
engine and a octree engine in a single big monolithic structure. It's not
going to work.But that aside...

> I did a Google search and couldn't find any 
> info on how to set up object transform managers to maximize 
> HW T&L, so if somebody knows of a term for this that would 
> help my search, please let me know.
> 
> Meanwhile, my questions are:
> 1.  Is anybody using quats for everything, including game 
> models, etc.?

We use quats to store animations, since they are compact.

> 2.  If so, are you building a new matrix from scratch every 
> frame for use by HW T&L?

Yes.

> 3.  For those using good old matrices, are you building the 
> matrices from scratch each frame or updating one?

We decompress quats to matrices, then composite the matrices together for
things like hierarchial animations.

> 4.  If you are updating, does modern hardware with T&L choke 
> because you are accessing memory?

No, why? It's maybe 20-odd matrices per person. this isn't a big problem.

> 5.  What are the implications of managing a whole bunch of 
> objects and keeping their transform matrices updated and 
> syncronized without chewing up performance?

It's not really a huge amount of work. And it isn't as if there's any
alternative.

> 6.  In the "old days" I built my engines to aggressively 
> check what angles changed and then called a function 
> specifically written to handle the minimal matrix update 
> needed.  Is this still a good way to do things?

I guess so, but it's frequently quicker to write straightline code with
fewer conditionals. You may do 10% more work (how many of your joint angles
don't change in a typical walk cycle? Not many), but that results in much
simpler code and nicer memory-access patterns. On today's CPUs, conditional
branches and memory accesses are your worst enemies. Multiplies are cheap.

> 7.  Are people still manipulating objects using an X, Y, Z 
> angle and then generating the matrices internally, or have 
> there other ways of doing this I should consider?  (e.g. 
> grabbing Look At/Right/Up vectors directly from the matrix 
> and manipulating them, etc.)

We store animations as either quaternions or as Euler angles as appropriate,
then convert them to matrices, and _then_ we do maths with them. Never
attempt to do maths with angles - you'll just hurt yourself on those
singularities. :-)

> Thanks!
> Brett Bibby
> GameBrains


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.