• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Kwizatz

Matrix Multiplication vs Compression Dilemma

5 posts in this topic

I am almost done with my skeletal animation file format specification, but I have come across a dilemma.

I am using animation channels which are arrays containing one value per frame, I came up with the idea of not storing the array if all the values are the same, so the value is stored only once, I call this, obviously, a constant channel.

From there I thought I could do something about other channels that change too little, for example for some sort of trigger channel, where values are mostly zeros with ones here and there to signal a sound or that a footprints, so I added Run Length Encoding channels.

So far so good but! once I came to store joint transformations I noticed that when I store full model space transforms, the children joints change as the parent changes because the transform 'includes' the parent's transform, so transformation vectors do not compress well this way.

However, if I store the joint transforms in 'parent space', if a joint never moves or rotates or scales, its values never change and thus, very good compression ratios can be achieved.

Now, the problem is that if I store the transforms in parent space, I still need to calculate the transforms in model space at run time, and that may involve several matrix multiplications that are avoided if the transforms are precomputed as is in the first case.

So my question is... what should I do? should I go for (perceived) speed or size? is this even a valid concern? perhaps the overhead is negligible, or maybe a smaller memory footprint compensates for the computation cost, I don't know.

Ideas? Discuss! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Edited by Kwizatz
0

Share this post


Link to post
Share on other sites
[quote name='Kwizatz' timestamp='1348003726' post='4981423']
So my question is... what should I do? should I go for (perceived) speed or size? is this even a valid concern? perhaps the overhead is negligible, or maybe a smaller memory footprint compensates for the computation cost, I don't know.
[/quote]

Don't go for perceived anything. Measure instead. Chances are the extra matrix multiplications aren't that expensive, since hardware has been optimized for that type of operation since computers were invented. Also, do you really need to compress all that much? How much animation data do you have and what platform is this for?
1

Share this post


Link to post
Share on other sites
Hi alvaro,

Well, the idea is for a general engine, but to be more specific I am targeting PC's (Windows, Linux) and Android, so going by the lowest denominator, lets say its for handheld devices, ARM processors.

Right now I don't have that much animation data, an uncompressed idle character loop is about 500k with just joint information, no morphs, quite insignificant, I know, but I like the idea of shaving as much as possible so it does not add up to a lot later on when I have more characters, vehicles, etc.

I could add a flag and allow the format to be flexible and let the asset pipeline decide based on where the files would be used, but if there really is no gain, I don't see why add the complexity.

You're right, I should measure... kind of what I was trying to avoid [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img].

I do realize this is probably early optimization, but I kind of want to nail down the format once and for all.

Thanks! Edited by Kwizatz
0

Share this post


Link to post
Share on other sites
I agree that it is early optimization. At this stage I would just spend some effort in making the animation representation modular, so you can implement other methods later on without having to change interfaces. You can then optimize when you have actual test cases.

On a related note, I think it only makes sense to write an engine by writing several games and then extracting the parts that have proven to be useful across projects (perhaps with a bit of reshaping to make them more engine worthy). More generally, that's a good approach for writing libraries of pretty much any type. Edited by alvaro
0

Share this post


Link to post
Share on other sites
I'll just add a flags variable to the file header and add one for this, the flags may be useful for something else later on.

Thanks!
0

Share this post


Link to post
Share on other sites
So, I know this is a very particular issue and maybe in the end a matter of taste, but just in case someone runs into a similar issue...
I found that storing parent space transforms may be the best approach after all since I am seeing some artifacts for interpolated frames that might be due to interpolating between model space transforms, so calculating each joint model space matrix at run time might be the best approach unless you don't mind jiggly animations (the closer you are to the model the more noticeable the artifacts are).

If you don't interpolate frames, then you're ok.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0