• 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
MrMark

Help with rotations in 2D around a particular point, using a scene graph

4 posts in this topic

Hi all

I'm getting myself confused with rotations in 2D when rotating about a point about another point. I'm using a simple tree as my scene graph. Each node knows its position relative to its parent, and there is a root node that is the ancestor of all nodes. So when I move a node all of its children move with it.

Rotations of a node about its parent are simple. But how do I rotate a node about another node ?

What I could find on the internet talks about translating the origin to the node being rotated around, rotating it, then translating back. So based on that, I came up with:

[list]
[*]From the node to be rotated walk up the tree to the root node building a translation matrix (1)
[*]From the origin node walk up the tree to the root node building a translation matrix (2)
[*]inverse the origin node's translation (2) matrix
[*]Form the origin translation matrix by multiplying matrix (1) by matrix (2), forming matrix (3)
[*]Multiply the node to be rotated by matrix (3). It's now a vector relative to the rotation origin
[*]apply rotation matrix
[*]multiply the node by the inverse of matrix (3), its now a vector relative to its parent again.
[/list]

But that seems somewhat over complicated, which makes me think I'm either doing it wrong, or have found a convoluted way of doing something simple.


Any help greatly appreciated.
0

Share this post


Link to post
Share on other sites
First of all, using a scene graph is, well, deprecated, but using it and ignoring its natural parenting seems me strange. Why do you want to rotate around grand-parent nodes?

However, here is the solution:

1. Every node has a position relative to its parent node and expressed as translation matrix [b]T[/b][sub]i[/sub] for the [i]i[/i]-th node. Every node has an orientation relative to its parent node and expressed as rotation matrix [b]R[/b][sub]i[/sub] for the [i]i[/i]-th node. Then the local transformation matrix of the i-th node is given by (using row vectors here)
[b]L[/b][sub]i[/sub] := [b]R[/b][sub]i[/sub] * [b]T[/b][sub]i[/sub]

2. The belonging global matrix, i.e. the transformation matrix relative to the overall common reference space (a.k.a. "the world") is computed as
[b]W[/b][sub]i[/sub] := [b]L[/b][sub]i[/sub] * [b]W[/b][sub]i-1 [/sub]= [b]L[/b][sub]i[/sub] * [b]L[/b][sub]i-1[/sub] * [b]L[/b][sub]i-2[/sub] * ... * [b]L[/b][sub]1[/sub]
where [b]W[/b][sub]i-1[/sub] denotes the global transformation matrix of the parent node. Please notice the recursive definition.

3. The center of rotation should be given by a node above the current one, e.g. [b]W[/b][sub]j[/sub] with 0 < j < i. As your internet source correctly stated, you have to make this temporarily the origin. You do this by applying the inverse matrix, because you go from global to local space. Hence
[b]W[/b][sub]i [/sub]* [b]W[/b][sub]j[/sub][sup]-1 [/sup]= [b]L[/b][sub]i[/sub] * [b]L[/b][sub]i-1[/sub] * ... * [b]L[/b][sub]j+1[/sub]
would do the trick. Now apply the rotation
[b]W[/b][sub]i [/sub]* [b]W[/b][sub]j[/sub][sup]-1 [/sup]* [b]R[/b]
and finally shift the temporary center back to its original position:
[b]W[/b][sub]i[/sub]' := [b]W[/b][sub]i [/sub]* [b]W[/b][sub]j[/sub][sup]-1 [/sup]* [b]R[/b] * [b]W[/b][sub]j[/sub]

4. If you want to know the local transformation, then do
[b]L[/b][sub]i[/sub]' = [b]W[/b][sub]i[/sub]' * [b]W[/b][sub]i-1[/sub][sup]-1[/sup]

Comparing this with the prescription given in the OP, you'll see the going from the current node up to the grand-parent node in the index sequence i-1 ... j+1 in the formulas above. Of course, you don't really need to compute [b]W[/b][sub]j[/sub] and [b]W[/b][sub]j[/sub][sup]-1[/sup] to just yield in the desired result [b]L[/b][sub]i[/sub]', because of
[b]W[/b][sub]i[/sub]' * [b]W[/b][sub]i-1[/sub][sup]-1[/sup] = [b]W[/b][sub]i [/sub]* [b]W[/b][sub]j[/sub][sup]-1 [/sup]* [b]R[/b] * [b]W[/b][sub]j[/sub] * [b]W[/b][sub]i-1[/sub][sup]-1 [/sup]= ( [b]L[/b][sub]i[/sub] * [b]L[/b][sub]i-1[/sub] * ... * [b]L[/b][sub]j+1[/sub] ) * [b]R[/b] * ( [b]L[/b][sub]j+1[/sub][sup]-1[/sup] * ... * [b]L[/b][sub]i-1[/sub][sup]-1[/sup] )
where the parentheses are only used for clarity (i.e. there is no mathematical necessity). However, due to the parenting mechanism you'll have to implement the computation of [b]W[/b] anyway.


EDIT: Please check the formulas twice before using it, because mistaking an index is done quickly ;( Edited by haegarr
1

Share this post


Link to post
Share on other sites
Thanks for an awesomely detailed post haegarr. I was able to follow the maths (which is rare =P).

Quick question, why are scene graphs deprecated ?
0

Share this post


Link to post
Share on other sites
[quote name='MrMark' timestamp='1337500981' post='4941601']
Quick question, why are scene graphs deprecated ?
[/quote]
Scene graphs are an example of violating the principle of single responsibility. It is used for logical grouping, assembling models, defining parent-child transformation hierarchies, doing spatial partitioning, ... all at once.

However, a single structure cannot do all this without enforcing restrictions. E.g. a scene graph naturally introduces a hierarchical bounding volume scheme. But what if you want to use a binary space partitioning scheme instead? Just an example. You'll find dozen of threads about this theme in GDnet as well as some articles on the internet.

I don't say that scene graphs are senseless, but IMHO using a single structure for each kind of job is the way to go today. Edited by haegarr
1

Share this post


Link to post
Share on other sites
Yes Scene Graphs are frustrating when you try to force everything inside the Scene Graph design.. it's just annoying and stupid to follow such goal.
1

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