0
\$\begingroup\$

I'm currently trying to remake/port an old game created on Unreal Engine 2.5 to my own engine, and I have access to its physics data. It's using a scale of 80 units per meter, or 1 unit = 1.25cm.

The walk speed value for example is 5, and physics is simulated at 60 FPS, so the walking speed I need to implement would be 3.75 meters per second.

But I don't exactly know what the size of a game engine's "unit" actually means. I of course want my own engine (I'm using C++, OpenGL, and GLM) to use this same scale, but I'm not sure how to go about that. I'd assume this affects not only physics/movement code, but the scale of models and maps I load in as well, so it's important to make sure it's the same as in the original game.

How would I implement this? What parts of a game does the size of a 'unit' affect and how? Just the physics and movement calculations, or the graphics side as well (matrices, clipping space, FOV, etc.)?

(I'm not sure if I'm overthinking things)

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
2
\$\begingroup\$

The length units, for 3D graphics, are whatever. As long as they are internally consistent, it does not matter. For graphics.

For physics units matter.

However, you do not set the units. There is nothing different in game engine or its settings. In fact, the units for most engine only exist in documentation and in the mind of people. Except time, because time is time.

Your game will have real units of time. You need to make your physics engine be consistent with that. In your engine, I suppose you would measure the elapsed time between frames, your delta time is some units. What units is that?

Figure out what is your unit for time. Then pick a unit for length. You can write it down in comments, or in some means of communication to other developers, or in a piece of paper. You are going to express everything with the units you picked.

For example, if you are trying to mimic earth gravity, and you set your gravitational acceleration to 9.8. What units is that? Well, that is meters over seconds squared. This means you are working with meters and seconds. You would have 980, if you were working with centimeters and seconds. 9800 for millimeters and seconds (also nanometers and milliseconds). 0.0000098 is meters and milliseconds. 0.0098 is millimeters and milliseconds. I'll reluctantly mention 32.15 is feet and second. And so on.

Remember that time is time. So getting speed and acceleration right, is important.

Of course, it makes sense to create models with whatever scale you are using for physics. What do I mean by that? Well, if you make a human, how many units tall should it be? Ah, units are whatever, but humans are around 1.6 meters tall. So, if you are working with meters, you make your human model 1.6 units. If you are working with centimeters, then it is 160 units. And so on. The graphics don't care, but remember that the the physics do.

If you create your models with the physics units, that will save you scaling the models. However, if you have to scale the models, that is not the end of the world. You would be using matrix transformations to place the models in the world anyway, it cost you nothing, nothing, to have those matrix transformations also scale the models appropriately.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Ok, there's one thing I don't understand. If you add 1.0 to the object's x value in the game I'm talking about - it moves a tiny bit, I would guess about 1.25cm. I imported the exact same model into my game, and changing my object's x from 1.0 to 2.0 in my engine is a HUGE movement, about a screen's worth. Definitely not 1.25cm. How do I make it the same? I don't understand why it doesn't move the same amount relative to the size of the model, since it's the same model. That's why I'm confused about this scaling and unit size stuff. \$\endgroup\$
    – Accumulator
    Apr 9, 2021 at 22:12
  • \$\begingroup\$ @Accumulator Double check the position of the camera. Is it too close (according to game units)? If it is too close, a small movement looks large. Also double check the field of view. Does it match what the old game had? A small field of view is like camera zoom, may also make movement look large. It is also possible that there is an scaling in the camera projection in the old game. \$\endgroup\$
    – Theraot
    Apr 9, 2021 at 22:22
1
\$\begingroup\$

The engine's units are whatever you want want them to be. Wether one unit is a centimeter and your character is 100 units tall, or one unit is a meter and your character is 1 unit tall, in both cases the result will be the same.
Plain numbers in a computer are unitless so you have to decide how to interpret them, i.e. what is their unit.

What's really important here is consistency. Your unit system has to be consistent throughout the whole application. Don't implement a function that works with altitude in meters, another one working with altitude in feet and send a probe to Mars.

In addition, you also want your system to be practical for your context: if you're implementing a game with normal-sized humans using time in seconds and distance in nanometers, you'll work with huge numbers that are impractical for the human brain (and incidentally can lead to problems with floating point numbers).
But the same problem arises if you're working on a game in which the entities are molecules and you choose the meter as a length unit.

Improve this answer
\$\endgroup\$
0

You must log in to answer this question.

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