And Now The 2006 Eias Hacking Contest!!


See the project I have uploaded at the web address below :

What I want to do? To be able to scale up or down Big_Cube and that Small_Cube keeps its relative x.position. For example if I move Small_Cube to the center of Big_Cube I want it not to move during the Big_Cube scaling or if I move Small_Cube to 0.25 in x.position (1/4 of Big_Cube width) I want it stands at 1/4 of Big_Cube width after scaling.

Rules :

  • You have the right to use as many Effectors as you want.
  • You can’t use any XP or EIAS constraints on Small_Cube. It has to be free.

Gains :

  • All my love.

Thanks all for any help.

Stephane CROUZET


Hi, Stephane



When I move the small cube to the top center of the big cube and then scale the big cube, I get the same displacement to the right with both scale_issues.prj and scale_issues2.prj
I’m missing something?


Hi, Richard

Yes, but Stephane asked about scale, right?:slight_smile:


Stephane wants the small cube to keep it’s relative position after the scaling of the big cube.


Igors good try but I was aware of this. The trouble with your project is that if you try to move the small cube further on its x.position, and scale the big cube, the small cube lose its relative position and that’s the problem I can’t seem to solve.


Hi Stephane,
When I saw your thread, I told myself, ‘be careful what you wish for. Here’s a new mini challenge’ :slight_smile:
Trying to scale the boxes according to the criteria you posted, I felt like trying to solve a Rubik’s cube puzzle (never could solve more than one face). I can’t scale the big box downwards, even using effectors, without breaking the positioning of the little box.

Why the prohibition against using XP? Not that I’m sure there’s a solution there (not very good with XP. Waiting for Ian’s Paralumino tutorial on that one).


I’m just prohibited XP here because the project for what is intended that thread will be full of XP scripts. :slight_smile: All will be controlled by XP. The only object that can’t is this small cube which represents a controller, so it has to be free of XP script or EIAS constraints to allow me to drive it in realtime and create keyframes when I want. But if there’s a solution with XP while maintaining that state, I have nothing against.

Note that what I am asking is not an easy task. I have lost perhaps 8 hours to test different things (thanks to EIAS), but some time you test so much that you become blind (I say that because it has already happened to me) and a new eye can’t be bad.

Plus, if the small cube stands at 0 in its x.position, all is correct and react as expected so I say myself it has to have a solution.


Okay, this one uses Xpressionist, but it should keep the manipulability you want…

::EDIT:: No it doesn’t… Why not? lol

Wow… I just learned something new about heirachys… I thuoght that if you scaled a parent, all the other objects moved in relative to the parents ACTUAL position, not relative to where it was when you parented it… heh
That’s weird…


Yes I was answering you when I saw your edit. That’s strange I thought like you but no. I have posted the message on the EIForum too to see if Matt Hoffmann could anwser me. Perhaps with the way the FBX hierarchy works lies the solution I don’t know. Thanks for the try anyway.


Okay, not entirely elegant, but this one works :slight_smile:

Basically, you have a controller separate from the actual small cube, which can be animated etc. On top of a box which represents the old box, so you have a reference.

So, when you’re animating, you control the refernce small box and the actual big box.

You can move the controller’s big box anywhere you want so it’s not in your way, it won’t affect anything.

Again, it uses XP, but it’ll keep your control over the small cube… Whether or not it’s directy.

::EDIT ::
One thing… It doesn’t work with rotations… :frowning:


Hierarchy uses Link position to transform child. The Link position can be changed in Link Editor but it’s not animated and it’s not changed if a child is moved. Thus Stephane’s puzzle has no solution without XP, constrains etc. “Inherit deforms = OFF” works in same way


Try playing around with the different hierarchy modes and values in the Link Window. It’s all a bit funky and there are many ways of doing things which is why there’s an FBX mode now.

What we found was that Classic and Standard didn’t have an equivalent to the FBX Local mode. MotionBuilder has three modes. Local mode effectively strips off any scaling that might be applied by the parent hierarchy but still scales any offset. We added this in 6.5.2.


Quick movie just to show it worked.

All I’ve done it moved the controller cube around in the X n Z axis, and then scaled the big cube in all axis… It works scaling in any one axis aswell, though.


Hmm… looks like it works with modern “FBX local” (see attachment)


Hey Igors, your project is quite good but not totally satisfying for me as the small cube is scaled too. I don’t want the small cube to be scaled. So the BJMonkey one is better for my use (thank you BJ) even if it is more complicated. I thought I would have found a simplier solution just with the way hierarchies works in EIAS, but it seems that no. So I will go that way if no-one find a better solution. Thanks for all your interest in my little thread.


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.