Maniphest T76593

Coordinate limit of 10,000 units, incoherence
Closed, Resolved

Assigned To
Campbell Barton (campbellbarton)
Authored By
Sebastien Larocque (SebBlender)
May 9 2020, 8:36 PM
Tags
  • BF Blender
  • Modeling
  • User Interface
Subscribers
Ankit Meel (ankitm)
Brecht Van Lommel (brecht)
Chris Kohl (ckohl_art)
Jacques Lucke (JacquesLucke)
Michael Soluyanov (crantisz)
Sebastien Larocque (SebBlender)

Description

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: rB9605c2616696

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.

Revisions and Commits

rB Blender

Event Timeline

Sebastien Larocque (SebBlender) created this task.May 9 2020, 8:36 PM
Michael Soluyanov (crantisz) added a subscriber: Michael Soluyanov (crantisz).May 9 2020, 11:50 PM
Chris Kohl (ckohl_art) added a subscriber: Chris Kohl (ckohl_art).May 11 2020, 9:00 AM
Ankit Meel (ankitm) changed the task status from Needs Triage to Confirmed.May 11 2020, 1:30 PM
Ankit Meel (ankitm) added a project: Modeling.
Ankit Meel (ankitm) added a subscriber: Ankit Meel (ankitm).

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

Jacques Lucke (JacquesLucke) added a project: User Interface.May 14 2020, 11:34 AM
Jacques Lucke (JacquesLucke) added a subscriber: Jacques Lucke (JacquesLucke).

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 (brecht) added a subscriber: Brecht Van Lommel (brecht).May 14 2020, 1:23 PM

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 (SebBlender) added a comment.May 14 2020, 5:49 PM

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.

Campbell Barton (campbellbarton) closed this task as Resolved by committing rBb487ef61161b: Fix T76593: Coordinate limit of 10,000 units.May 18 2020, 1:28 PM
Campbell Barton (campbellbarton) claimed this task.
Campbell Barton (campbellbarton) added a commit: rBb487ef61161b: Fix T76593: Coordinate limit of 10,000 units.