Coordinate limit of 10,000 units, incoherence #76593

New Issue

Sebastien Larocque · 2020-05-09T20:36:11+02:00

2020-05-09 20:36:11 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 441.28

Blender Version
Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-05-06 16:18, hash: 9605c26166

Short description of error
Coordinate limit of 10,000 units, incoherence

Exact steps for others to reproduce the error

Create an object and go to edit mode.
Select a vertex.
In the vertex coordinate fields, enter a value of more than 10,000 units.
Blender will limit the value to 10,000 units.

Problem

I know this limitation is a feature part of the software and it is not a programming bug. Based on what I read, the reason was a precision issue. However, I decided to report it as a design bug instead for the following reasons.

There is a paradoxical and illogical aspect in this behavior.

First, the limit exists only when editing the value directly into the value field. Despite this limitation, I can still use the move gizmo to move the vertex many times beyond the limit of 10,000 units. The move gizmo allows to move the vertex, but not editing the field value. Where’s the difference in that? Mainly, we do not have the possibility to enter a precise value, but the move gizmo allows to move the vertex.
Second, scaling up an object and applying the scale transform still works. All the vertices could be beyond the 10,000 unit limit.
Third, as a workaround, if I move the origin of the object close to the target vertex, I can enter my value up to 10,000 units because the limitation works relatively to the origin. Once done, I can move back the origin to what it was and the edited vertex stays beyond the 10,000 unit limit.

Therefore, this behavior only limits the user when editing a value directly into the value field. Otherwise, a user can create an object with vertices beyond the 10,000 unit limits when using other editing methods and the result still works well. That raises the question of having this limitation when editing the value field manually.

Recommendation and solution

I recommend removing this limitation. If you really need to work with the precision issue, please warn the users instead when using values beyond the problematic threshold. There might be an option to check/uncheck. This way, Blender does not prevent users who really need to work with high values.

Example of a typical case

To justify where it does not make sense for me, here is an example.

I have a landscape in Blender to be exported to the Unity game engine. The landscape is a simple mesh with mountains and a width of more than 30,000 meters. Therefore, the vertices are beyond the 10,000 unit limit. During the editing, I used the move gizmo to edit the vertices and to shape the landscape. I exported the mesh to Unity and everything worked fine. Yet, I could not edit the vertices manually beyond the 10,000 unit limit when I needed a precise value that I could not enter with the move gizmo. The values are still close to 10,000 compared to someone who would edit the whole planet Earth. Editing a landscape is a common scenario for game developers and if there is a value limit, at least it should be within a more realistic range. The landscape with the mountains does not need to have a high precision in that case.

Therefore, it is paradoxical to be able to complete the process and use a functional mesh with values far beyond 10,000 units, but not be able to edit a couple of vertices manually with more precise values.

{F8523540 size=full}

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 441.28 **Blender Version** Broken: version: 2.83 (sub 15), branch: master, commit date: 2020-05-06 16:18, hash: `9605c26166` **Short description of error** Coordinate limit of 10,000 units, incoherence **Exact steps for others to reproduce the error** * Create an object and go to edit mode. * Select a vertex. * In the vertex coordinate fields, enter a value of more than 10,000 units. * Blender will limit the value to 10,000 units. **Problem** I know this limitation is a feature part of the software and it is not a programming bug. Based on what I read, the reason was a precision issue. However, I decided to report it as a design bug instead for the following reasons. There is a paradoxical and illogical aspect in this behavior. * First, the limit exists only when editing the value directly into the value field. Despite this limitation, I can still use the move gizmo to move the vertex many times beyond the limit of 10,000 units. The move gizmo allows to move the vertex, but not editing the field value. Where’s the difference in that? Mainly, we do not have the possibility to enter a precise value, but the move gizmo allows to move the vertex. * Second, scaling up an object and applying the scale transform still works. All the vertices could be beyond the 10,000 unit limit. * Third, as a workaround, if I move the origin of the object close to the target vertex, I can enter my value up to 10,000 units because the limitation works relatively to the origin. Once done, I can move back the origin to what it was and the edited vertex stays beyond the 10,000 unit limit. Therefore, this behavior only limits the user when editing a value directly into the value field. Otherwise, a user can create an object with vertices beyond the 10,000 unit limits when using other editing methods and the result still works well. That raises the question of having this limitation when editing the value field manually. **Recommendation and solution** I recommend removing this limitation. If you really need to work with the precision issue, please warn the users instead when using values beyond the problematic threshold. There might be an option to check/uncheck. This way, Blender does not prevent users who really need to work with high values. **Example of a typical case** To justify where it does not make sense for me, here is an example. I have a landscape in Blender to be exported to the Unity game engine. The landscape is a simple mesh with mountains and a width of more than 30,000 meters. Therefore, the vertices are beyond the 10,000 unit limit. During the editing, I used the move gizmo to edit the vertices and to shape the landscape. I exported the mesh to Unity and everything worked fine. Yet, I could not edit the vertices manually beyond the 10,000 unit limit when I needed a precise value that I could not enter with the move gizmo. The values are still close to 10,000 compared to someone who would edit the whole planet Earth. Editing a landscape is a common scenario for game developers and if there is a value limit, at least it should be within a more realistic range. The landscape with the mountains does not need to have a high precision in that case. Therefore, it is paradoxical to be able to complete the process and use a functional mesh with values far beyond 10,000 units, but not be able to edit a couple of vertices manually with more precise values. {[F8523540](https://archive.blender.org/developer/F8523540/BlenderVertexValueLimit.jpg) size=full}

Sebastien Larocque commented

2020-05-09 20:36:11 +02:00

Added subscriber: @SebBlender

Michael Soluyanov commented

2020-05-09 23:50:22 +02:00

Added subscriber: @crantisz

Michael Soluyanov commented

2020-05-09 23:50:22 +02:00

Duplicate https://developer.blender.org/T39882

Chris Kohl commented

2020-05-11 09:00:56 +02:00

Added subscriber: @ckohl_art

Ankit Meel commented

2020-05-11 13:30:33 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-05-11 13:30:33 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Ankit Meel commented

2020-05-11 13:30:33 +02:00

That was in 2014. If this still needs to go to todo, confirming it first.

Jacques Lucke commented

2020-05-14 11:34:20 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2020-05-14 11:34:20 +02:00

When working with objects that large, you should consider changing the "Unit Scale" in the scene settings. It exists exactly for that purpose. Simply increasing the limit will probably just cause more bugs in other areas of Blender.

We could have a warning that pops up when you start having an object with huge dimensions, but I'm not sure how that should look like.

When working with objects that large, you should consider changing the "Unit Scale" in the scene settings. It exists exactly for that purpose. Simply increasing the limit will probably just cause more bugs in other areas of Blender. We could have a warning that pops up when you start having an object with huge dimensions, but I'm not sure how that should look like.

Brecht Van Lommel commented

2020-05-14 13:23:40 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-05-14 13:23:40 +02:00

I don't think there should be a limit on these values, we don't have one for e.g. object location either. While very small or large values have precision issue, there's no reasonable single limit we can defined to prevent that, as the actual precision issues also depend on the usage of e.g. modifiers or constraints. We leave this up to the user.

As far as I can tell this is just old code from when buttons had to have a limit to function properly, but now we support setting -FLT_MAX FLT_MAX and that can be used here.

I don't think there should be a limit on these values, we don't have one for e.g. object location either. While very small or large values have precision issue, there's no reasonable single limit we can defined to prevent that, as the actual precision issues also depend on the usage of e.g. modifiers or constraints. We leave this up to the user. As far as I can tell this is just old code from when buttons had to have a limit to function properly, but now we support setting `-FLT_MAX` `FLT_MAX` and that can be used here.

Sebastien Larocque commented

2020-05-14 17:49:30 +02:00

Here’s some extra information about my bug report and another demo project illustrating the problem.

It’s true that floating point numbers lose their precision when the number increases. As far as I remember what I studied at school, the more you increase the number before the dot, the more imprecise it becomes after the dot. For example, if 3.1415926535 works well, 1000000.1415926535 will not work as well. Therefore, working with high precision numbers require to have relatively low numbers before the dot. This where we can lose precision and where it could be problematic.

Furthermore, I created another small project to illustrate the conditions where we seem to lose the precision. There are two planes. Each plane is 2000 x 2000 units where the red plane is 1 meter above the green plane.

On the screenshot, we can see a rendering problem in the editor where the planes are overlapping, even if the red plane is still 1 meter above the green plane. In the 3D view, when using the viewport shading “Solid” or “Material Preview with Eevee” and only with these two, some artifact can be seen.

The artifacts on the green and red planes can be seen only when zooming very far away. If I zoom in close to the planes, I do not have these artifacts. This might be related to the z-buffer in DirectX.

It’s worth mentioning that Cycles never had this problem. I have another scene with a sky dome of 45000 meters, and Cycles renders perfectly. However, in the 3D when editing, there are artifacts if two meshes are too close to each other.

To reiterate on the purpose of this change, having large meshes works very well in games. For example, editing a mountain. The most important point when exporting a large mesh for your game is to consider the precision scale like this:

For a background mountain landscape, the vertices will probably have distances between 50 and 200 meters. The precision value after in the dot is never a problem and in that case and we could even use integers.
If the character is going to walk on that mountain, creating many small high-precision parts of that mountain is the way to go.
Large meshes have already been used in games for years without any problems.
Exported meshes already work properly. When exported, they use large numbers.
Blender already supports numbers larger than 10000, except in one scenario: entering the value manually in the fields and pressing enter.

{F8535548 size=full}

Unit_Limitation2.blend

Here’s some extra information about my bug report and another demo project illustrating the problem. It’s true that floating point numbers lose their precision when the number increases. As far as I remember what I studied at school, the more you increase the number before the dot, the more imprecise it becomes after the dot. For example, if 3.1415926535 works well, 1000000.1415926535 will not work as well. Therefore, working with high precision numbers require to have relatively low numbers before the dot. This where we can lose precision and where it could be problematic. Furthermore, I created another small project to illustrate the conditions where we seem to lose the precision. There are two planes. Each plane is 2000 x 2000 units where the red plane is 1 meter above the green plane. On the screenshot, we can see a rendering problem in the editor where the planes are overlapping, even if the red plane is still 1 meter above the green plane. In the 3D view, when using the viewport shading “Solid” or “Material Preview with Eevee” and only with these two, some artifact can be seen. The artifacts on the green and red planes can be seen only when zooming very far away. If I zoom in close to the planes, I do not have these artifacts. This might be related to the z-buffer in DirectX. It’s worth mentioning that Cycles never had this problem. I have another scene with a sky dome of 45000 meters, and Cycles renders perfectly. However, in the 3D when editing, there are artifacts if two meshes are too close to each other. To reiterate on the purpose of this change, having large meshes works very well in games. For example, editing a mountain. The most important point when exporting a large mesh for your game is to consider the precision scale like this: * For a background mountain landscape, the vertices will probably have distances between 50 and 200 meters. The precision value after in the dot is never a problem and in that case and we could even use integers. * If the character is going to walk on that mountain, creating many small high-precision parts of that mountain is the way to go. * Large meshes have already been used in games for years without any problems. * Exported meshes already work properly. When exported, they use large numbers. * Blender already supports numbers larger than 10000, except in one scenario: entering the value manually in the fields and pressing enter. {[F8535548](https://archive.blender.org/developer/F8535548/PlanesOverlapping.png) size=full} [Unit_Limitation2.blend](https://archive.blender.org/developer/F8535547/Unit_Limitation2.blend)

blender-admin commented

2020-05-18 13:14:36 +02:00

This issue was referenced by b487ef6116

This issue was referenced by b487ef61161b6249255be43314a0e1cfa4c9f0ee

Campbell Barton commented

2020-05-18 13:28:24 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2020-05-18 13:28:24 +02:00

Campbell Barton self-assigned this 2020-05-18 13:28:24 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Coordinate limit of 10,000 units, incoherence #76593