Is there any specific reason why UE developers chose to go with Centimeters as default unit for distance? It’s specially confusing because Speed/Velocity unit is Meters per Second.
What are the advantages and disadvantages to changing the default unity from Centimeters to Meters?
I guess in terms of numeric precision, centimeters are closer to unit which can describe small things equally well as large things (bunch of coins on a table as well as bunch of buildings in a city.
It is because it is.
There’s no point in questioning it. If you don’t like it, open the source and change it.
But in the end it won’t really change anything.
Units of measures are fluid.
They can always be scaled and transformed from A to B so it really doesn’t matter what the base unit is considered to be.
Except that if you go imperial then you can’t *100 to get to a meter, which potentially makes things harder.
However it really doesn’t matter.
Speed velocities are represented in m/s for convenience.
Scientifically when looking at bullet trajectories and the like scientists user meter per second.
Americans use feet per second.
Usually if you look up the data on an ammo box (the few that have data tables that is) muzzle velocity is reported as both m/s and f/s
Since the times we enter in velocity is mostly related to projectiles, the fact it’s in m/s is a convenience factor of not having to convert it.
If he’s just curious I think my reply explains it.
It doesn’t really matter what you pick as the base unit. A unit is a unit. Conversion is always possible moving forward…
It is because it is.
There’s no point in questioning it. If you don’t like it, open the source and change it.
But in the end it won’t really change anything.
It doesn’t answer my question. And for the record, it will change things because of float precision.
Since the times we enter in velocity is mostly related to projectiles, the fact it’s in m/s is a convenience factor of not having to convert it.
The same logic is applied to other units. Since most objects are big and are not moved by centimeters (for example players often move 4 to 6 meters per second), isn’t it more convenient to represent distance as Meters?
Anyway, This question is not about how units of measurement work. I know units can be converted and somewhat arbitrary in real world. But in binary they are not arbitrary. With Centimeters you cannot have actors placed further than 640 meters or you will start to experience slight jitter (and it will get worse on every power of two). It’s pretty weird for an engine that markets itself for big worlds to have Centimeters as default; hence this question. I want to know if there’s a reason that I’m missing behind the decisions of UE engineers.
In this engine there is literally NO reason on ANYTHING.
With regards to floating point precision, the engine has trouble past 2km no at 640m.
And even then, it’s pointless to argue that “it’s built and maketed for large words” or whatever - a large world will always require world origin shifting. The engine does include the function.
It’s also fairly easy to set up for “infinite” geometry without ever incurring into floating point issues in practice.
I doubt you’ll ever get an answer as to why - but here’s hoping.
Yes, this guys at Epic don’t know what they are doing. They probably tossed a coin to decide between centimeters or meters.
Edit: Let me add Sarcasm in case someone doesn’t get it
In this engine there is literally NO reason on ANYTHING.
In case you wasn’t aware, it doesn’t cost you anything to not reply to questions you don’t know the answer to.
With regards to floating point precision, the engine has trouble past 2km no at 640m.
If we want to discuss it scientifically, floating point precision problem is always present. You can have the problem right from 0.
The threshold in which you deem it as “trouble” is arbitrary and is not the point of my thread.
The point is, with cm as default unit, you will reach more “trouble” a lot “sooner” than meter as the unit. Which makes Centimeters worse as an option for “default” unit .
I want to know why Epic engineers chose the worse option for the default option.
And even then, it’s pointless to argue that “it’s built and maketed for large words” or whatever - a large world will always require world origin shifting. The engine does include the function.
It’s also fairly easy to set up for “infinite” geometry without ever incurring into floating point issues in practice.
You should probably try and ask this during a live stream with a technical writer.
I doubt you’ll get any sort of answer regardless.
You aren’t exactly wrong that floating point precision becomes an issue sooner, buy you do sound paranoid about a non-problem.
The only way you notice anything is if animations jitter or if rendered items look weird. Neither of those issues occurs much even around 8km from origin.
(If you are making scientific stuff, wft are you doing in engine anyway? There’s math lab for that…)
This engine is literally falling apart, and full of incomplete work. The base unit is likely the last thing they’ll ever even consider worrying about.
Also, in regards to architecture, CM provides much cleaner views.
Last thing:
Engine settings - editor appearance - units.
Change to your hart’s content.
(I doubt it’s more than a multiplication in practice, you’d need to test to see if it makes any difference for floating point precision)
Absolutely, but it wasn’t always that way.
Remember when 1uu was like .75m or some such nonsense? That was definitely 4 already… They made the jump to CM some 4 years ago I think.
if OP is curious on the history of it, you can probably find it commented in the git-hub release when reviewing changes.
Not an Epic engineer, but choosing centimetres as the base unit affords more precision on smaller scale things such as character animations.
It’s worth noting that the engine does have support for tagging properties with a unit type in C++, and there is an editor preference for changing the preferred display units based on the property unit metadata. This isn’t widely used in the engine though, iirc.
It’s also worth noting that in UE5 there is the Large World Coordinates functionally which changes all types relating to position from single to double precision. This is enabled by default in UE5 afaik. So using the tag stuff above means that you can make changes in your preferred unit of choice and not really have to worry about loss of precision at either the low end or the high end.
After the whole community wanting to know why on earth they weren’t using doubles to begin with for over 7 years… this is probably the “least” they could have done to try and savage the engine.
When it comes to 4.27 though, that’s still an issue.
There’s some cpp lib I shared once upon a time that exposes and allows for doubles in BP - and there’s also a few Rama powered cpp scripts for near exactly the same thing.
Thing is, you’d have to write your own custom character movement to use it for movement, and it won’t do jack for animation tracks (but animation tracks are local normally so you only run into the issue if you use world position for IK).
The problem is the inconsistency - if you set meters in the editor, then place your object at (1, 0, 0) and then print the coordinates, you will still get 100, 0, 0 printed on the screen. Sure, you can use types and other methods to make sure you don’t mess things up, but you can’t just pretend that 1 unreal unit = 1 meter, that will break your displays in the editor.
if you have to use formulas (and you need to convert to SI for all the constants to align), then it’s just an ever-present multiplication/division that’s really annoying.
Possibly because the metric measurement system is in units divisible by 10 instead of 12, being that most display resolutions are also perfectly by 10 maybe it’s better for formatting who knows really, the first game