"1 unit = 1 meter" vs "10 units = 1 meter"

What you guys think is the best size for a meter in game? Tell me your pro and against agruments.

Ill start, i have noticed that when using 1 unit as 1 meter nav mesh agent starts to get in way. Like if you want your character to turn around instantly, and it just wont, no matter the angular speed. Then default values in nav agent seems to be made for bigger characters.

 

Yeah you definitely want to make sure to use the right scale, otherwise everything will be messed up. Lightmapping, navigation baking will take forever, physics will be wonky, shadows and fog get F***ed.

 

I agree, but the question is what is the right scale.

 

Unity starts off expecting one unit to be one meter. You can always use a different amount but anything expecting the default will have to be modified to use the new scale. Therefore my argument against changing it is I'm lazy.

 

I like one meter per unit because it's easy and Unity's physics are kind of set up around that assumption for reasonable defaults.

By default it's 1 unit = 1 meter.

 

It really depends on what type of game you are making. For all of your standard FPS or RPG types I would run with the standard 1 unit is 1 metre. It makes everything work nicely, especially things like nav mesh agents, character controllers and built in physics.

However if your game is non standard, just choose a scale that makes sense. For example Revenge of the Ghosts is played on a 2D board that is 16 units by 16 units. Treating one unit as one square wide makes all of the math really convenient.

Or ignore scale altogether. Pond Wars is about 5 units by 5 units. Because that was the size of the default camera.

 

I am currently using 1 unity unit = 0.10 m because I made a mistake when I first started using Unity, and didn't realize the problem before it was too late. But everything is fine as long as you keep your settings to agree with your scale.
For example for my lightbaking resolution it is at 0.4, because that is equivalent to 40 using the 1 unit = 1 m.
I would strongly recommend leaving it at 1 unit = 1m.

Also, if you buy particle systems from the asset store, a lot of them expect the proper scale, otherwise you have issues with particle speeds and gravity.

If I started over, I would've left the scale alone, but I'm too far along now to go back, especially when I hard-coded Vector positions in your scripts that would need to be changed.

 

It would depend on your world scale as the responsiveness of the physics collision is based upon this setting.

 

I haven't done the maths but the characters in my game ( atleast the more "normal-sized" ones ) are 3 units tall, walls of a single floor 5 units, etc etc. Partially since the first sketches of characters I drew to use as blueprints in my 3D tool ended up with those units, but also as I've played around a little with the character proportions I have been more focused on keeping objects in a size that are somewhat proportionate and fit together with other objects and ignored counting meters.

It work for me and I haven't had any trouble with it neither for physics or anything else, although my mesh sizes aren't extremely far away from the recommended 1u/1m so I can't say for 10 m / 1 unit.

 

That is actually a very good argument against custom size (considering that 1 unit is 1 meter).

However there is also a very good argunet for using bigger sizes, the floating point problem, whene ints deliver a much better precision as floating point values.

 

I hope you aren't suggesting increasing the scales just so you can cast transform positions from floats to ints. I can't imagine that would work out well. Maybe I don't understand what you mean. Could you give an example of what you are hoping to do with the int?

 

Well i can't realy tell the full story there but i had to use 5 units as a meter because of floating point problems. Yes i would agree that it depends on what you do. Like in a usual rpg you probably don't have that problems but in a game like minecraft positioning is way to important so you probably wanna use more reliable values.

 

Still makes no sense to me. Exactly what "floating point problems" are you referring to?

 

Are you referring to precision issues that occur beyond a certain distance? Or the Z-fighting effect where the graphics card cannot precisely determine which triangle renders in front of another? Neither of these problems requires unusual values.

The former can be solved by using a floating origin. Basically the loaded sections of the world are shifted back to the origin (zero) point of the world. This keeps the world within the precision limits of floating point values.

The latter is solved by multiple cameras rendering different sections of the world. Kerbal Space Program, for example, uses about four cameras. One for the UI, one for the immediate vicinity, one for very far objects, and one for the mid-range.

 

If you are piloting a fast vehicle over large distances, scaling everything down will help with physics. You loose precision. But at high speeds that doesn't matter.

 

Do you have a source for any of these claims? I don't really respect the default scale in a lot of the projects I make. Only if I rely on third party assets or try to make something realistic in 3D to I stick with the 1 unity = 1 meter rule. In any 2D project I make I usually use 1 unit = 1 pixel which according to you should screw up everything, but from my experience everything works as it should and having 1 unit = 1 pixel when working with 2D is very intuitive. You can snap everything to the unit grid which then becomes the pixel grid and everything just feels like a 2D engine using integers, and not like a 3D engine where you're positioning a 0,32x0,32 sprite (32x32 pixels) on a seemingly random point on a floating point grid.

 

For my 2D I will often do the same. One unit represents one grid space or one water division or whatever.

 

You call it a solution, i call it a workaround. Specially in case of position indexing you have to round position before and after every calculation. While if you index them in ints, you will only have to round them once.

 

The way I see it units are simply a way of representing relativity to each other rather than an actual measurement. They're an arbitrary number to use in whatever way makes sense for the project. If you're working with tiles then 1 unit = 1 tile makes sense, or 1 unit = 1 pixel, etc. If there's no significant reason to do it differently then 1 unit = 1m is fine. That's how unity understands the world by default so it's easier that way, or just adjust unity to suit your scale. Up to you to determine the right way.

 

It's a better alternative to fudging the values or converting to other types. Floating origin is very easy to implement.

 

Considering the example is 5 units per meter, the floating origin solution is a bit different, as that's normally used for extremely large scales, not small.

Out of curiosity, what was the use case that required that scale?

 

I was prototyping a space engineres like project. Basically people make ships from parts then fight each other. Those parts are actually made of invisible boxes, like you see a wall but server sees a bunch of boxes. It was fun and i still think it is a good idea but project was coming forward too slow so i switched to another.