We are making a game where the main character is a gingerbread man in a house. Is it better to have gingerbread man be small( ~ .2 units tall) and have everything else normal sized ( kitchen table about 2 units tall) or have him be normal sized (let’s say 1 unit tall) and have everything else be huge( table would be about 10 units tall).
Making a character controller .2 units tall might have some undesirable results depending on the controller. I’d go with the character being normal sized.
My current issue is that when I have the character increased to 1 unit(normal sized), all speed calculations are slower(which makes sense). This includes gravity. When my character is .2 units, using real life gravity (9.8 x time.deltatime^2) seems really realistic and smooth but when the character is 1 unit, I have to increase gravity to make it natural. This is easy to do, but I kind of like the idea of using as many real life calculations as possible. It just helps me think of things easier. What undesirable results should I be weary of? Also, is there any difference in performance between the two?
1 Like
It’s still a real-life calculation, just like 9.8 meters a second is exactly the same as 980 centimeters per second. You’re just measuring gingerbread-men-per-second instead of meters.
1 Like
In terms of the physics, I can’t give exact reason in terms of things like moi and maximum velocity when dealing with gravity. However, I know a little from trial and error from an experiment I did a few years ago. The experiment involved a spaceship in a solar system (huge open world) and I was trying to clumsily work-around the floating point issue when you have a large open world in Unity. In my experiment, I made everything smaller like you are talking about doing in order to work around this…I since learned that floating point can be addressed via scripting like “World Streamer” asset does.
The smaller I made things, it seemed to have an effect on things like hit boxes, physics, colliders, and at a certain point of “shrinking” things, the controller I was using was not usable. I’m not 100% sure why and there could have been dependencies that relied on the controller maintaining default scale in unity for reasons unknown and/or not mentioned here.
Some optimization advantages to make things smaller overall (which I honestly know a little bit more about than the above):
-
The file sizes of your saved meshes/models on disk will be smaller if they are small meshes that are scaled larger. The file size of your obj, fbx’s etc will be smaller. This might affect hit boxes and colliders adversely (at a certain degree of upscaling) depending on your needs (like bullet decals look bad if you shoot a wall and the decal is floating in the air not connected to anything). Somebody more knowledgeable might be able to address this easily via scripting; I don’t know for sure.
-
Your camera does not have to draw as far of a distance. One example, if you are using occlusion culling and you bake this culling for your scene, it going to be a smaller file size in a smaller map/scene thus smaller memory footprint.
There are other things that might come into play where someone else might be able to shed some light…like what about mip maps and tiling say floor peices from a texture atlas…not sure how scaling would affect this, but there could be other things like that.