PDA

View Full Version : Rotation Frustration


GruvDOne
08-27-2008, 10:03 PM
I am not sure why, but apparently my Cinema 4D thinks that H and B are the same thing.

Basically, I have a compass model that I want to make a simple gyroscope animation for. However Cinema does not want to play.

Here is the model.. notice the rotation co-ordinates:

http://web.me.com/williefrazier/Project_Gallery/Blank_files/shapeimage_2.jpg

Ok, so now, I enter a value into H and this is the result:
http://web.me.com/williefrazier/Project_Gallery/Blank_files/shapeimage_4.jpg

Fine... so now, I reset the H rotation and put a value into B:
http://web.me.com/williefrazier/Project_Gallery/Blank_files/shapeimage_3.jpg

The result is the same! How can this be? For reference, I then reset B and put a value into P and get this:
http://web.me.com/williefrazier/Project_Gallery/Blank_files/shapeimage_5.jpg

This bit I want to rotate like a wheel, and yet when I attempt to do this using the rotation tool... only moving it on one axis, changes appear in all three fields:
http://web.me.com/williefrazier/Project_Gallery/Blank_files/shapeimage_6.jpg


So, what gives? Why is, what should be the mist fundamentally simple of tasks inspiring such frustration?

Machine in use is a MacBook Pro, OSX 10.4, C4D 10.5

MarcCG
08-27-2008, 10:29 PM
I dont really understand hpb (nor do most peolpe apparently!) that well, so

a long shot, but in the preferences there is a setting under units called "use HPB system", try flicking that switch and see if anything changes, I know at one point I switched it off because its just greif! with a capital G.

Horganovski
08-27-2008, 10:29 PM
This is the way rotations work in Cinema, Cactus Dans' rigging tutorials demonstrate this and discuss some workarounds. For your case probably the easiest thing to do is to put the object you want to rotate inside a 'root' null which has the same position and orientation as the object itself, then you get a clean 0,0,0 starting point for rotations on your object and when you keyframe one of them you'll get predictable results.

HTH,
cheers,
Brian

GruvDOne
08-27-2008, 10:33 PM
For your case probably the easiest thing to do is to put the object you want to rotate inside a 'root' null which has the same position and orientation as the object itself, then you get a clean 0,0,0 starting point for rotations on your object and when you keyframe one of them you'll get predictable results.


Yeah, this is typically the workaround I use, but I was more interested in getting to bottom of why it works this way. If this is how Maxon has programmed their rotations to work, then it is flawed and should be corrected.

Thanks.

MarcCG
08-27-2008, 10:36 PM
Yeah, this is typically the workaround I use, but I was more interested in getting to bottom of why it works this way. If this is how Maxon has programmed their rotations to work, then it is flawed and should be corrected.

Thanks.

well, its not flawed, its an alternative system because of how 3d rotations work mathmatically, to avoid something called gimbal lock (!) which I havn't come across even though I've turned the setting off I said.

Cactus Dan
08-27-2008, 11:04 PM
Howdy,

We all feel your pain :sad:

The programmers haven't done anything wrong, as MarcCG said. Rotation in 3D space is something that mathematicians have been struggling with for centuries, and no one has come up with a "fix all" solution, yet. We recently were discussing rotations in this thread:
http://forums.cgsociety.org/showthread.php?f=47&t=667471

Adios,
Cactus Dan

Sneaker
08-28-2008, 11:29 AM
The Catus Dan's mechnical rigging tutorial (http://www.c4dportal.com/cactusdan/Mechanical.zip) should be mandatory before anyone sets a keyframe for rotation.
Something like a drivers license for animating with rotation ;)

-Michael

GruvDOne
08-28-2008, 05:49 PM
The Catus Dan's mechnical rigging tutorial (http://www.c4dportal.com/cactusdan/Mechanical.zip) should be mandatory before anyone sets a keyframe for rotation.
Something like a drivers license for animating with rotation ;)

-Michael


Downloading it now, thanks :)

I noticed that when employing the null object work around, using the Option-Click method to automatically induce parenting, the null - as expected - takes on all of the positional and rotational properties of it's child object, including this 'odd' sort of behavior described in my original post. Odd that resetting the Null's baseline rotation to 0,0,0 resolves it.

It seems to me then, that there is still something anomalous in the equation used to determine 3D Rotation. I suspect that one day some pioneering mathematician wunderkind will come along and set the whole world on it's ear with a solution... but until that time work around it is.

Thanks all
Will

xfon5168
08-28-2008, 05:57 PM
Yeah, this is typically the workaround I use, but I was more interested in getting to bottom of why it works this way. If this is how Maxon has programmed their rotations to work, then it is flawed and should be corrected.

Thanks.


Welcome to hell.

The best advice I can give is this. Don't type in values. Use the bands and look at the rotations in the Coordinates Manager. Second, Solve for the H first. H has top Priority, then P, then B. You can see this easily. Rotate the P band to some arbitrary number first. then Rotate the B. No problems right?

Now Rotate the H, then the P. Shouldn't encounter any problems. But if you try rotating B, then H, or P then H, well now the H is changing the rotations of P/B because it needs to be solved first. It's essentially the parent of P and B. Same if you Rotate B then P. It will do the same thing. So you just need to rotate the orders right. So in your example, if you know you want it 35 degrees on the H, hold SHIFT and drag to 35 on H first, then SHFT Drag on P to 90 or what have you. When you begin to think about this you can get it to work for you. I used to encounter this a lot with Hand Controllers, but now I know how I can get around it.

that's my crummy explanation. :shrug:

Horganovski
08-28-2008, 07:31 PM
Well, for character animation you can always go the hardcore route - and key every frame:D
The computer is a pretty crap in-betweener most of the time anyway..

Cheers,
Brian

Constrict
08-28-2008, 07:37 PM
Hi,

coming from MAX i find this a bit odd. I use(d) to type in rotation values in 3ds max all the time without any problems (or atleast any unexpected results), in both local(object) space and world space. I see a lot of c4d forum posts addressing the problem so wouldnt a peak at how other software packages solve this problem be an idea? Being new to Cinema i find a lot of the interface and functions to be very intuitive and easy to grasp, but such a basic(but apparently mathematically difficult) task as rotating and getting an "unlogical" result is definitely frustrating. I personally love to work parametrically so hope there will be some solution to this in a future software update.

Cheers!

- Colin

51M0N
08-28-2008, 08:19 PM
It seems to me then, that there is still something anomalous in the equation used to determine 3D Rotation. I suspect that one day some pioneering mathematician wunderkind will come along and set the whole world on it's ear with a solution...

That will probably happen when the computers get smart... For now they're pretty dumb!

GruvDOne
08-28-2008, 10:57 PM
Hi,

coming from MAX i find this a bit odd. I use(d) to type in rotation values in 3ds max all the time without any problems (or atleast any unexpected results), in both local(object) space and world space. I see a lot of c4d forum posts addressing the problem so wouldnt a peak at how other software packages solve this problem be an idea? Being new to Cinema i find a lot of the interface and functions to be very intuitive and easy to grasp, but such a basic(but apparently mathematically difficult) task as rotating and getting an "unlogical" result is definitely frustrating. I personally love to work parametrically so hope there will be some solution to this in a future software update.

Cheers!

- Colin

Well this used to be true of C4D as well. As I recall I only started having these 'issues' after R10... maybe R9... Not entirely certain when the change took place. But I do know that when I started back with R 7.3 (called XL7 back then), I didn't encounter this, though I would occasionally run into the dreaded Gimbal Lock on occasion.

xfon5168
08-28-2008, 11:59 PM
Well this used to be true of C4D as well. As I recall I only started having these 'issues' after R10... maybe R9... Not entirely certain when the change took place. But I do know that when I started back with R 7.3 (called XL7 back then), I didn't encounter this, though I would occasionally run into the dreaded Gimbal Lock on occasion.

XL7 had this problem as well. I just checked :D.

GruvDOne
08-29-2008, 04:41 AM
XL7 had this problem as well. I just checked :D.


I don't know what's more disturbing... the fact that my memory fails me, or that you still have a copy of 7 laying around ;)

xfon5168
08-29-2008, 06:10 PM
I don't know what's more disturbing... the fact that my memory fails me, or that you still have a copy of 7 laying around ;)

You never know when your job calls for it. I have version 6, but lost the serials....i hope my job doesn't call for 6. :D

CGTalk Moderation
08-29-2008, 06:10 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.