Bug in R12+

On 31/07/2013 at 19:26, xxxxxxxx wrote:

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

---------
Howdy,

There seems to be a bug in R12+ regarding setting an object's matrix. To see the bug, create a null object at world center. Then set its X scale to -1. Then write this little bit of code in a CommandData plugin:

Bool TestCommand::Execute(BaseDocument* doc)  
{  
  BaseObject *op = doc->GetActiveObject();  
  if(op) op->SetMg(Matrix());// set to identity matrix  
  EventAdd(EVENT_FORCEREDRAW);  
    
  return TRUE;  
}

... and rather than resetting the object's matrix to the identity matrix (which should be 0,0,0 position, 1,1,1 scale and 0,0,0 rotation coordinates) it sets the object's coordinates to:
Position 0,0,0
Scale -1,-1,1
Rotation 0,0,-180

What's causing this? It doesn't happen in versions prior to R12.

Adios,
Cactus Dan

On 06/08/2013 at 01:54, xxxxxxxx wrote:

Hi,

This is correct behavior. SetMg just makes sure that the matrix position is reached and this can be done using a lot of different combinations.
If you want to set the identity values you need to use op->SetRelRot(0.0) and op->SetRelScale(1.0)

On 06/08/2013 at 06:53, xxxxxxxx wrote:

Howdy,

So, is the reason this behavior wasn't present in versions prior to R12 because R12 introduced the "Freeze Transformation" option?

Well, the issue isn't really setting an identity matrix, but setting an object's matrix to a transformation matrix that is built through matrix calculation. If the user sets a scale parameter to a negative number, then there are unexpected results. Even though the object's matrix will be positioned and oriented correctly, the PSR coordinates won't be displaying correctly. That makes it a bit more difficult when writing code to predict all the things a user might do. :angry:

Adios,
Cactus Dan

On 06/08/2013 at 19:14, xxxxxxxx wrote:

Originally posted by xxxxxxxx

If the user sets a scale parameter to a negative number, then there are unexpected results.  ...That makes it a bit more difficult when writing code to predict all the things a user might do.

I think there may be some deeper problems, for example:

1. make a cube, set R.H to 45 °
2. make a null, set S.X to 0.5
3. drag the cube under the null
4. drag the cube back out
5. repeat steps 3 & 4 a few times

This is what you should see, using any version greater than R11:
[FLASH WIDTH=420 HEIGHT=204]http://downloads.simplesoftwaresystems.com/cinema/img/killer-null.swf[/FLASH]
According to comments in my code, I found this particular pattern when attempting to polygonize some objects under a hypernurbs using combinations of MCOMMAND_CURRENTSTATETOOBJECT and MCOMMAND_JOIN; in the course of cloning, un-parenting, and re-parenting the involved objects, some of them seemed to be taking on confusingly random transforms, and it did not make much sense until I found I was able to reproduce the behavior purely using the Cinema UI.
It seems like a bug, but then, it also seems so fundamental that it gives me the feeling it might just be something that everybody already knows about, except me.

On 07/08/2013 at 01:31, xxxxxxxx wrote:

This isn't related to Freeze Transforms.

If you'd reset the matrix to the original scale (1/1/1) then each time you'd apply a matrix for routines like IK etc. the scale of the object would get lost.
The object tries to keep its scale as the scale of an object usually is changed the least often.

If you don't want the behaviour call op->SetRelScale(1.0); before; that should set the identity matrix like desired.

On 07/08/2013 at 07:45, xxxxxxxx wrote:

Howdy,

Well, as I mentioned above, setting an identity matrix was only used as an example of the issue.

But, the solution is to store the object's scale and rotation before setting the object's matrix to a calculated matrix, so that the scale and/or rotation can be restored after setting the object's matrix (only a few lines of extra code :wink:)

Adios,
Cactus Dan

On 07/08/2013 at 07:51, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...I think there may be some deeper problems,...

YIKES! Now that is scary. :astonished:

Adios,
Cactus Dan