Rotation question

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/12/2005 at 10:59, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.2 +
Platform:   Windows ; Mac ; Mac OSX ;
Language(s) :     C++ ;

---------
Howdy,

I have a problem with comparing a saved rotation with the current rotation. They should be exactly the same but they're not. They print out the same, even if I set the printout to six decimal places, but the comparison is always returning false after a position change and an undo.

Here's the code:

  
     Vector opRot = op->GetRot(), savedRot = tagData->GetVector(SAVED_ROTATION);  
     if(opRot != savedRot)  
     {  
          GePrint("rotation changed");  
          GePrint("opRot = "+RealToString(opRot.x,-1,6)+","+RealToString(opRot.y,-1,6)+","+RealToString(opRot.z,-1,6));  
          GePrint("savedRot = "+RealToString(savedRot.x,-1,6)+","+RealToString(savedRot.y,-1,6)+","+RealToString(savedRot.z,-1,6));  
     }

The rotation is saved at the end of the tag's execution and should be the same the next time the tag executes if the object hasn't been rotated. The problem arises when I change the position of the object and do an undo. It then prints to the console that the rotation changed (and the two vector printouts are the same) when really only the position changed.

Of course an easy fix for it was this code:

  
     Vector opRot = op->GetRot(), savedRot = tagData->GetVector(SAVED_ROTATION);  
     if(opRot != savedRot)  
     {  
          Bool sameRot=TRUE;  
          GePrint("opRot = "+RealToString(opRot.x,-1,6)+","+RealToString(opRot.y,-1,6)+","+RealToString(opRot.z,-1,6));  
          GePrint("savedRot = "+RealToString(savedRot.x,-1,6)+","+RealToString(savedRot.y,-1,6)+","+RealToString(savedRot.z,-1,6));  
          if(RealToString(opRot.x) != RealToString(savedRot.x)) sameRot = FALSE;  
          if(RealToString(opRot.y) != RealToString(savedRot.y)) sameRot = FALSE;  
          if(RealToString(opRot.z) != RealToString(savedRot.z)) sameRot = FALSE;  
  
          if(!sameRot)  
          {  
               GePrint("rotation changed");  
          }  
          else GePrint("rotation same");  
     }

But, I don't understand why the first code doesn't work after a position change and an undo. A position change alone doesn't make the comparison fail. Is there an imprecision in the roundoff and how many decimal places does the number actually have, or how many decimal places does the comparison check?

Adios,
Cactus Dan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/12/2005 at 12:35, xxxxxxxx wrote:

Because of imprecision in floating point numbers, it would be better to do an epsilon test (where you set a small deviation value to compensate for any imprecision). There is a function in the SDK called VectorEqual() which does the compare using an epsilon value and may prove useful in your situation. Just set the epsilon to the smallest value that would be a significant cause for the vectors to be unequal.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/12/2005 at 16:02, xxxxxxxx wrote:

Howdy,

Ah, ok I didn't know about that function. Thanks Robert. It is exactly what I needed. Works like a charm.

I should've taken a closer look at the c4d_tools functions.

Adios,
Cactus Dan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/12/2005 at 19:54, xxxxxxxx wrote:

This is one of those gotchas with programming digital computers. Two good books for handling floating point mathematics, if you ever need to get into writing your own trigonometric functions or doing FFTs and so forth, are:

- "Numerical Recipes in C++" (or C, 2nd Ed.)

- "Math Toolkit for Real-Time Programming"

The first is ubiquitous, but many veteran programmers have found flaws and issues with their algorithms over time.

The second is indispensible. It is written by a real veteran programmer in real-time embedded systems who knows his stuff (NASA, Physics PhD, Alliant, first program in 1956 - when neither of us were even a twinkling in our parents' eyes).

One of the reasons that I suggest these, especially the latter, is that every programmer is eventually faced with utilizing higher mathematical functions (FFTs, Eigensystems, Chebyshev approximation, Calculus, etc.). And with these come the shortcomings of computer floating point numbers and operations thereupon. Probably the worst situation is when you start performing long operations and are unaware that each iteration is losing precision (and you end up with more of a 'Chaotic system' rather than a stable calculation).

There are some good tools in C4D's Math tools. Nearly all of these are taken directly out of "Texturing & Modeling: A Procedural Approach".

Take care and Happy Holidays!