StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4895577
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-02-04T07:30:17.663
FavoriteCount
0
LastActivityDate
2011-02-04T07:35:36.147
LastEditDate
2011-02-04T07:35:36.147
LastEditorUserId
70881
OwnerUserId
70881
ParentId
4893040
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
IMO, the most 'user friendly format' for rotation is storing Euler XYZ angles, this is generally how rotations are exposed in any 3d content creation software. Euler angles are easy to transform to matrices, see <a href="http://en.wikipedia.org/wiki/Rotation_representation_%28mathematics%29#Conversion_formulae_between_representations" rel="nofollow">here</a> for the involved matrix product. But you should not confuse the format given to the GUI/user and the storage format of the data: Euler XYZ angles have problems of their own when doing animation, <a href="http://en.wikipedia.org/wiki/Gimbal_lock" rel="nofollow">gimbal lock</a> can introduce unwanted behaviour. Another candidate for storing/computing rotations is <a href="http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation" rel="nofollow">quaternions</a>. They offer mathematical advantages over XYZ angles, essentially when interpolating between two rotations. Of course, you don't want to expose the quaternion values directly to any human user, you'll need to convert them to XYZ angles. You'll find plenty of code to that on the Web. I would not recommend storing the rotation directly in matrix format. Extracting user friendly values from it is difficult, it does not offer any interesting behaviour for animation/interpolation, it takes for storage. IMO, matrices are to be created when needed to transform the geometry. To conclude, there are a few options, you should select what suits you most. Do you plan to having animation or not ? etc. EDIT Also, you should not make an amalgam with model and view matrices. They are semantically very different, and are combined in OpenGL only for performance reasons. What I had in mind above in the 'model matrix'. The view matrix is generally given by your view system/camera manager, and is combined with you model matrix.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POCompact representation of OpenGL modelview matrix 4x4
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USrotoglup
UserOwnerUserId
1. USrotoglup
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.