Object´s scale is decreasing less than expected

Question

So object B is moving, let´s say, 4 units to left. There is object A, which will be squeezed that exact distance. So if its scale is 10, - the 4 units will be = 6. As simple as that, but for some reason this isn´t working. Am subtracting the exact same distance object B is going through, but even though object A´s scale decreases, it decreses less than expected, like 3 instead of 4. That number is accumulating over frames.

I have verified several times that the number subtracted is indeed the correct number, and the script that makes this is executed after object B´s movement. Any ideas of what could this be?

Edit: I have discovered something. Instead of just subtracting the 4 units, am also subtracting the value of how much is going through, which I get using raycasts. Now, the interesting part is that, even though this number should be 0, is something like -0.002.. and is no longer accumulating, but it still becomes bigger and bigger (I think this is because the number is a percentage from the size reduction, which becomes bigger every frame). This is less noticeable than before. The raycast is thrown before the movement itself, so I think that am subtracting the extra value of the former frame. And the moving object is supposed to stop for a frame before going through. Why the moving distance isn´t enough?

Answer 1

Answer by Sibz9000 · Mar 12 at 10:02 PM

Scale is not number of units, it's a multiplication of size.

If your object, lets say cube for simplicity is 1x1x1, then a scale of 10 makes it 10x10x10 However if its 1.2x1.2x1.2, then a scale of 10 makes it 12x12x12.

So if we remove 4 from the scale of the first example, we get the expected size 6x6x6.

However in the second example we get 7.2x7.2x7.2 - not 8x8x8 as you may think.

If we have a smaller than 1 size, lets say 0.8x0.8x0.8 then the decrease would be less:

0.8x0.8x0.8 scaled by 10 = 8x8x8

Minus 4 from scale = 0.8x0.8x0.8 scaled by 6 = 4.8x4.8x4.8

The result is a size reduction of only 3.2, less than the 4 you would expect if thinking that scale is size.

Add comment · Show 5 · Share

Feref2 · Mar 12 at 11:41 PM 0

Share

Sorry, I forgot to mention that am doing this (transform.localScale.x * originalSize.x - moveUnit) / originalSize.x; That way I get the correct number and translate it into the transform Scale.

Sibz9000 Feref2 · Mar 13 at 08:41 AM 0

Share

Oh right, sometimes code really helps. If you can, post the important lines of what you are doing.

Feref2 Sibz9000 · Mar 13 at 07:42 PM 0

Share

float uScale = grounds[i].transform.localScale.x * groundScripts[i].originalScale.x; //groundScaleX[i] is first calculated. Is the final ground. groundScaleX[i] = (groundScaleX[i] - uScale) / 2;//Now changes to the half of how much is decresing or increasing from the current scale (am recycling variables to avoid garbage) for example (3 -5) / 2 = -1 is decreasing (the half is because the other object decreases the other half); Vector3 newScale = grounds[i].transform.localScale; newScale.x = (uScale + groundScaleX[i]) / groundScripts[i].originalScale.x; grounds[i].transform.localScale = newScale;

//the object that moves is connected to this ground (the floor´s reduction is what causes it to move). Logically speaking, it moves the groundScaleX[i] value.

Then there´s the other script which makes this:

currentX = transform.localScale.x * originalScale.x + leftRay.extra + allSizes.groundScaleX[leftGroundId]; //here am adding an extra ray from other script that measures how much is going through. This almost completely get rid of the issue, but that ray is thrown before.

//here´s the thing: even though the ray value should be 0 (if the object is perfectly colliding at the edge and isn´t going through) is something like -0.002..., but not constant. Subtracting this number really helps, but after some frames the issue appears again. I think this is because the ray shows how much ended up going through at the end of the previous frame. Throwing the ray after is complicated since I must calculate every position for the ray to be accurate, and after that, recalculate all grounds, which leads to recalculating this as well and is not good for performance, speacially because of how large the operation really is. Then the ray value from before - how much is decreasing should, logically, tell me this without needing to positionate everything beforehand. This was my original intention with the code line above, but again, for some reason the object needs to decrease more than the groundScaleX[i], which shouldn´t in the first place.

Show more comments

Object´s scale is decreasing less than expected

1 Reply

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions