Floating point values in the inspector are forcibly rounded to 3 decimal places

[pbalter]

Godot version: 3.0.2

OS/device including version: Arch Linux

Issue description:

Fractional numbers, when entered in the inspector of the editor, e.g. for the Height of a CapsuleShape, are rounded to two decimal places. For example, when entering 2.022 it will be rounded to 2.02 and when entering and 5.555 will be rounded to 5.56.

The issue could be mitigated by assuming different units, e.g. assuming 1 unit = 1 cm instead of 1 meter. 5.555 would become 55.55 and that would be fine (two decimal places now). However, this again does not work for more fractional places, e.g. 1/3. Additionally, the editor seems to be optimized for something like 1 unit = 1 meter or at least 1 ft because the zoom feature (mouse wheel) does not allow zooming out far enough to make it work with cm or inches.

My suggestion is to not round the values at all and leave them at 32 bit IEEE 754 representation. I don't see any benefit from forcing to round the values. Alternatively, allow setting the decimal places via the preferences menu.

Steps to reproduce:

1. Create a CollisionShape node and set it to CapsuleShape
2. Enter 5.555 as height value and accept
3. Observe the value changing to 5.56

[Vega-KH]

TL;DR - We will need to list exactly what properties need additional precision.

Functionality is already in the engine to change this on a property by property basis. The precision is set for each property like:

ADD_PROPERTY(PropertyInfo(Variant::REAL, "bias", PROPERTY_HINT_RANGE, "0,0.9,0.001"), "set_bias", "get_bias");

This particular property is the bias in 2D joints, and if you look at it in the editor, you will see that it has precision in 3 digits after the decimal. Many properties have 2 digits after the decimal for ease of use (you don't need more than 2 digits on things like animation speed.) In the transform section, you may notice that position and scale allow full 32 bit precision exactly like you mentioned in the issue post.

Height and width could probably use one more digit of precision. Are there additional properties that need to be adjusted?

[pbalter]

I think it would be great to make this configurable in the editor. How about a setting that allows for a global minimum precision? That allows for per-property precision settings as they are now but with the possibility to overwrite them all if desired.

Personally I don't see the benefit (i.e. the ease of use) in having less precise values. If it is just for the looks, it should be possible to just visualize a certain number of digits but keep the 32 bit value internally.

Unfortunately I am just starting to use Godot and the radius and height of the CapsuleShape were the first encounter of this issue - I don't know what other properties could need adjusting yet.

[aqnuep]

This is in fact a limiting issue. I just tried to use 1/16 as the value for the scaling of UV coordinates and you already get problems due to not being able to represent the value at 3 decimal points (Vector3 type default limits).

Also, apparently the min/max values for the components of a Vector are also limited to the [-65535,+65535] range which also doesn't make much sense when you have much more precision on anything but 16-bit floats.

[akien-mga]

There are various things behind what is discussed here:

1. The step used by SpinBox, Tree and EditorSpinSlider uses the step value to define the increment value for the slider/spinbox, so it needs to be a reasonable amount for the increment to be meaningful. The problem is that this value also limits what kind of values can be typed in manually. https://github.com/godotengine/godot-proposals/issues/3524 is the issue which tracks this problem.
2. The default step value for those controls is 0.001, so three decimal places. It's sufficient in most cases, but not always as exemplified here. This should be solved by #30776 which adds a configurable default float step, where you can put e.g. 0.00001 for five decimal places, or 0 to lift the limit (you then hit the internal limits hardcoded in String::num()).
3. Some properties have hardcoded hint ranges which are more restrictive than the now-configurable default 0.001, e.g.:

   scene/3d/particles.cpp
   385:    ADD_PROPERTY(PropertyInfo(Variant::REAL, "speed_scale", PROPERTY_HINT_RANGE,  "0,64,0.01"), "set_speed_scale", "get_speed_scale");

   For such properties, the inspector will indeed forcibly round to two decimal places, even if you configured 5 or unlimited after #30776. That's also part of #19242 where setting a hint range should not forcefully limit the precision of manually typed numbers.

So this issue can likely be closed eventually as partly fixed by #30776 (point 2.) and superseded by https://github.com/godotengine/godot-proposals/issues/3524 (points 1. and 3.).

[akien-mga]

Also see #25470 for some more context/discussion on what should be implemented ideally.

[aaronfranke]

I personally don't like seeing tons of decimals, so I disagree with showing everything by default. It would make sense to use the "default float step" setting from #30776 in as many places as possible, it's an ideal solution, as configuring this to be smaller (or zero) should work fine for your use cases.

The question I have is that why are some things hardcoded to a different value already? Why limit some things to multiples of 0.01 when others are limited to multiples of 0.001? If there is no actual reason for this, then replacing all similar hardcoded limits with default float step is a good idea.

Additionally, the editor seems to be optimized for something like 1 unit = 1 meter or at least 1 ft

The recommended practice for 3D is to always keep a real world scale, and meters make everyone's lives easier. Of course, Godot doesn't explicitly say "meters", so you can change the scale as you wish, but most things will assume 1 unit = 1 meter so it's best to use that too. EDIT: Godot 4.0 explicitly says meters :)

[Zireael07]

This is not only an issue in the inspector, it's also an issue for the debugger. Yesterday, I was working on some calculations that started with a super small value (something something)e-07, and resulted in something..e-05 (i.e. 0.000000) The debugger showed this as 0.000, both input and output, leading me to think the whole function does not work and only some sleuthing via in-game labels, which happily show four or more significant digits, allowed me to realize that it does in fact work.

For debugging, this is a very significant issue.

[Flavelius]

Not sure if it's related to this problem, but when setting the step value in float shader hints (range) to 0.25 the displayed value in the inspector gets rounded up (1.3 for example instead of 1.25) and upon trying to edit the value the expected 1.25 that should be there is still not shown, which lead to believe that this is a bug that actually just steps the value to 1.3. And it seems to only ever display one decimal place in that case.

[aaronfranke]

@Flavelius Seems like another place that should use the default float step setting.

I'm assigning the junior job label (currently "hacktoberfest") to this issue, fixing this issue in any or all of the various places it exists should be doable for new contributors.

[Calinou]

I think we should do the following:

• Add a Manual Step property to SpinBox and EditorSpinSlider, which should be set to a value lower than or equal to Step. If set to 0, Manual Step is ignored and Step is used instead (for compatibility).

  • In SpinBox, Manual Step should default to 0 for compatibility. In EditorSpinSlider, this should default to the lowest non-zero value (such as 0.0000001, possibly even lower in double-precision builds).

  • If Manual Step is lower than 1.0 and Step is greater than or equal to 1.0, it's ignored on integer properties. This means the behavior on integers remains unchanged in both SpinBox and EditorSpinSlider.

• When setting values manually or entering values with the keyboard, values are rounded according to Manual Step instead of Step.

• When setting values by dragging the mouse or arrows, values are rounded according to Step.

  • SpinBox has Custom Arrow Step for arrows, but EditorSpinSlider lacks this (so the same step as mouse dragging is used instead).

[kotx]

Would be great if this were addressed if possible. The number of closed duplicates seem to indicate this is important.

Currently being limited to 1.7778 on an AspectRatioContainer causes my subviewport size to be 1920x1079.987... not sure what effect this would have in the long run :(