1
\$\begingroup\$

TL;DR: Can I set the size of a collider in meters instead of fractions of the size of the object it's in?

I'm implementing a classic NES game, and my scale is 1 meter = 16 pixels. I have an 8x1x1m prism with a rigidbody, and I need its box collider to be smaller than it by one pixel on every side- to have the dimensions (8 - 1/16 - 1/16) x (1 - 1/16 - 1/16) x (1 - 1/16 - 1/16). (I'm subtracting the width of two pixels from each dimension because each dimension corresponds to two sides.)

When I set the size of the collider to (0.5, 1, 1), though, it interprets those numbers as fractions of the size of the prism instead of as meters. This results in a 4x1x1m collider instead of a 0.5x1x1m collider. Is there a way I can set the size in meters instead of percents? I'll save me a little bit of math, and, more importantly, it could prevent some floating point errors, especially if I switch to a scale with more pixels per meter.

\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

I usually use a transform hierarchy like this:

Entity Object -> Visual -> Collision

The "Entity Object" is at unit scale (1,1,1) and contains the rigidbody and whatever the "main script" for a particular entity is. This keeps the inspector clean and means the transform viewed by the main script is predictable.

The Collision object is also kept at unit scale, so the units used in the collider(s)'s inspector fields are world units (meters).

The visual and its children can be at any transform you want, without impacting the physics or interpretation of the inspector properties of the others.

This pattern also makes it easy to make variants on a game entity which use the same rules/behaviours but a different visual/collision.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.