Jump to content
  • Advertisement
Sign in to follow this  
dragonmagi

Now, what about rotations about origin

This topic is 4554 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was wondering if anyone had done performance tests on "real world" games/simualtions comparing rotations about arbitraty pt versus about origin, e.g. in opnGL. To be specific, there are two cases I am intersted in: 1) same as discussed in last thread: rotating the viewpoint about origin/arbitrary pt or, in third person mode, where the viewpoint pivots about an origin/pt centered on avatar. 2) rotating about moving avatar, where the origin (0,0,0) moves with it. In this case tho, the viewpoint follows behind on an elastic tether, e.g. trying to keep in the corridor and not go thru walls like in Morrowind. Futher, the axis of rotation and pivot of the following viewpoint is not same as axis of rotation of avatar. Reason I ask :In the second case, I believe, you have to apply a rotation matrix to the scene objects because you cannot apply inverse transform to the viewpoint to get correct effects: the objects move relative to the moving avatar not camera. And, as you know, rotations about (0,0,0) require less operations. So, I was wondering if anyone had done tests on such cases, or if they know there won't /will be some difference in performance.

Share this post


Link to post
Share on other sites
Advertisement
Hello again :)

I can't say this authoritatively, but IMO your concerns with respect to performance are misplaced. A complete discussion of all the issues involved would be somewhat lengthy, but from what I've gathered from your posts, I don't think it's something you should be worrying about.

Without getting into too much detail, I'll just say this. As we were discussing in the other thread, D3D and OpenGL see things primarily in terms of one or two matrices that transform geometry from one space (generally world, model, or embedded model space) to another (camera space). In this context at least I'll say again that all conceptual approaches to a camera or rendering model - first person, third person, non-transformed models, transformed models, hierarchical models, or what have you - will result in (more or less) the same amount of work for the hardware.

Also, regarding the notion that rotation about the origin requires fewer operations... With most geometry, the cost of transformation is dominated by the application of the composite matrix to the geometry, not in the construction of the matrix itself. This is one of the primary reasons that we express transformations in matrix form: no matter how many transforms you combine into a single matrix, they can still be applied to a vertex with a single matrix-vector multiplication.

Well, I said I wasn't going to get into too much detail, so I'll close with this. If I'm reading what you're saying correctly, then I would advise you not to worry about the performance issues you're refering to. Just work on implementing the functionality that you want, and if at some point you start to have problems with framerate or what have you, then you can start thinking about where optimization might be useful.

Just as a caveat, I'm not an expert on rendering hardware, so I suppose it's possible that there's something I'm overlooking here. But I think the above advice is probably sound.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
Hello again :)

..

Without getting into too much detail, I'll just say this. As we were discussing in the other thread, D3D and OpenGL see things primarily in terms of one or two matrices that transform geometry from one space (generally world, model, or embedded model space) to another (camera space). In this context at least I'll say again that all conceptual approaches to a camera or rendering model - first person, third person, non-transformed models, transformed models, hierarchical models, or what have you - will result in (more or less) the same amount of work for the hardware.

Also, regarding the notion that rotation about the origin requires fewer operations... With most geometry, the cost of transformation is dominated by the application of the composite matrix to the geometry, not in the

It's the composite matrix that I'm thinking of, actually. For example, a rotation about a z axis, centered on the origin, has two zeros in the fourth column first two rows in the composite matrix. If it is not centered at origin then there are 6 additions, 4 mults and 4 trig ops (Watt and Policarpo, 3D Games). Multiply this by 3 for x and y axis components in an aribtrary axis of rotation (18 additions, 12 mults and 12 trig ops).

So I suppose it comes down to whether the code (or openGL) does all those extra ops even when the matrix elements are zero. if it does not then there are a lot of ops saved per vertex rotated. Similar argument for scaling, just less ops.

I'm just asking because it will be a while before I can get to test it all out on something real myself and I was hoping someone had run some tests on the difference: rotation about pt versus about origin.

Anyway, thanks for your pointers - it all helps to give me a clearer idea of what goes on at the transform matrix level in the pipeline. An yeah, I know one can't generalise too much as most people will have different optimisations.

cheers

Share this post


Link to post
Share on other sites
Quote:
Original post by dragonmagi
Quote:
Original post by jyk
Hello again :)

..

Also, regarding the notion that rotation about the origin requires fewer operations... With most geometry, the cost of transformation is dominated by the application of the composite matrix to the geometry, not in the

It's the composite matrix that I'm thinking of, actually. For example, a rotation about a z axis, centered on the origin, has two zeros in the fourth column first two rows in the composite matrix. If it is not centered at origin then there are 6 additions, 4 mults and 4 trig ops (Watt and Policarpo, 3D Games). Multiply this by 3 for x and y axis components in an aribtrary axis of rotation (18 additions, 12 mults and 12 trig ops).
cheers


Ah I just realised what you were driving at: all those extra ops are performed in the construction of the modelview matrix yielding one value in each of the two places (0,4 and 1,4) and it is just those values that get multiplied by the vertices in the scene. So, potentially, only two extra multiply/add ops per (x,y,z) vertex when non zero. Still extra, just not much.

So my next question is, :), do those other (18 additions, 12 mults and 12 trig ops) extra ops make much diff to performance of constructing the matrix?



Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!