0
\$\begingroup\$

It's possible the following is fundamental to Unity, and not a problem?

I am using an example of a WheelJoint2D/Car from the Ray Wenderlich tutorials. Note from the pic below, the top level game object called "Car". It has children of "Body" which contains the wheel joints and the wheels (attached to the wheel joints). The top level "Car" GameObject is placed in the scene (here at X=6.4).

enter image description here

Now we run the game for a short time, and the car rolls forward as expected. From the inspector, we would see that X position of the Body and the wheels has changed, but note that the Car game object's X position has not changed:

enter image description here

So, in reality the game object "Car" has grown in the X-dimension. Granted this growth seemingly has nothing to do with physics simulation (as all the rigidbodies and joints are moving along as expected). One interesting side affect is that this growth might make scaling the parent object problematic.

But it seems that if this were an infinite runner, you would have an ever increasingly wide "Car" object. On the surface this seems undesirable, but is it really? And if so, how would you mitigate this (given that this game object hierarchy seems to be the prescribed way of using the wheel joints).

\$\endgroup\$
1
  • \$\begingroup\$ If you put the Rigidbody on the root car object then the whole thing will move as one, which might be more intuitive (so another script ref referencing the "Car" doesn't mistakenly read it as stationary, because it forgot to reach down to its "Body") \$\endgroup\$
    – DMGregory
    Aug 10, 2018 at 18:58

1 Answer 1

1
\$\begingroup\$

While large colliders or large renderer bounds can be a problem (ie. big stuff), large position offsets (with big nothing in between) are generally not a problem until you start running into floating point precision loss.

Unity doesn't ever need to do anything in particular with the span of space between a container object's local 0,0,0 point and a child object's position (or the span between the positions of two child objects moving in opposite directions) so this offset itself doesn't introduce more processing load. They don't make the containing object's transform "bigger" because transforms don't have a size (only stuff like renderers or physics colliders do); transforms are just rotations/shifts/scales to apply to their contained objects.

To deal with floating point precision issues in an infinite runner to to ever-increasing positions, you'll want to either move the world toward the player character (who stays close to zero), or periodically re-center everything so you stay in the higher-precision range. This doesn't really relate to how big something is though, just how far it is from the world origin.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks, a couple of things: As you suggested moving the rigid body (and wheel joints) to the top level (I ended up deleting the body altogether) made things move as one. But, thanks for confirming there is no actual practical issue unless the physics or rendering engines get somehow involved (growing collider size for example). As I mentioned, the practical downside of the original example seems to be you can't really easily scale the parent object (without taking into account it's X-dimension growth). \$\endgroup\$ Aug 10, 2018 at 19:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .