And Now The 2006 Eias Hacking Contest!!

#1

See the project I have uploaded at the web address below :
http://guetapens.wip.free.fr/projects/scale_issues.sit

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

#2

Hi, Stephane

Attached

#3

Errā€¦
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?

#4

Hi, Richard

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

#5

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

#6

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.

#7

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).

#8

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.

#9

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ā€¦

#10

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.

#11

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:

#12

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

#13

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.

#14

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.

http://www.x1.ltd.uk/brooks_website/scale_issues4.mov

#15

Hmmā€¦ looks like it works with modern ā€œFBX localā€ (see attachment)

#16

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.

#17

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.