> 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.
|
