Page MenuHome

Inset faces tool is fairly inaccurate
Closed, InvalidPublic

Description

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.48

Blender Version
Broken: version: 2.81 (sub 13), branch: master, commit date: 2019-10-04 22:33, hash: rBab519b91b2c4
Worked: (optional)

Short description of error
The inset faces tool doesn't have the vertices track exactly along an edge. In many cases it's off enough to cause modelling problems.

Exact steps for others to reproduce the error

  1. Default startup file. Delete the cube.
  2. Add a cone, radius 5, depth 10.
  3. Go into edit mode and select all of the faces of the cone except the circle.
  4. The edge length of the long edge is sqrt(5^2+10^2)=11.1803398875. Inset the edges by that amount.
  5. Zoom in and have a look at the tip of the cone. The vertices are off significantly, not just a little bit. The vertices actually converge at around z=5.097 instead of 5, which is 1% off over a distance of 10m. Thus the inset faces tool is not tracking correctly along the edges. I think 0.5% to 1% error, depending on how you calculate it, is unacceptable for such a simple mathematical operation.

  1. This happens at any scale. Make the cone 50m radius and 100m tall and you get the same issue.

Details

Type
Bug

Event Timeline

i can duplicate this problem on linux Blender2.81 ab519b91b2c4 , OpenSUSE Tumbleweed/KDE, AMD FX8350, 16GB DDR3, GTX690 2+2 GB VRam- Nvidia drivers 435.21, Factory Setting applied

IMO this is not a bug but a known limit of mathematical precision of the blender and rounding of mathematical values
IMO this mathematical error should be limited to 1/1milion not fractions of percent

i can duplicate this problem on linux Blender2.81 ab519b91b2c4 , OpenSUSE Tumbleweed/KDE, AMD FX8350, 16GB DDR3, GTX690 2+2 GB VRam- Nvidia drivers 435.21, Factory Setting applied
IMO this is not a bug but a known limit of mathematical precision of the blender and rounding of mathematical values
IMO this mathematical error should be limited to 1/1milion not fractions of percent

It can't possibly be a rounding error at 1%. Something else must be going on.

we will see when a developer checks this, IMO is a sum of rounds of many mathematical calculations used to execute the function (inset) in 3D space. i not check this bu i yhink we have same (or very near) result rounding inset value at 4th decimal number instead 10th and this number is already rounded in calculator that you have use

we will see when a developer checks this, IMO is a sum of rounds of many mathematical calculations used to execute the function (inset) in 3D space. i not check this bu i yhink we have same (or very near) result rounding inset value at 4th decimal number instead 10th and this number is already rounded in calculator that you have use

This is arithmetic that can be done by hand (pencil and paper only) to orders of magnitude better than Blender. I really don't think it's a 'rounding' problem. I'd say look for code that uses pi=3.14 but that should still get you an order of magnitude closer than what I'm seeing.

dark999 (dark999) added a comment.EditedSat, Oct 5, 9:22 PM

NO bug here, repeating same step of report but instead enter only value number try to insert =11.1803398875, top vertex are coincident, i suppose Blender use a rounding in input UI

mine result after all step with =11.1803398875 in inset value

see T58730 and https://docs.blender.org/manual/en/2.80/scene_layout/object/editing/transform/control/numeric_input.html?highlight=numeric%20input

NO bug here, repeating same step of report but instead enter only value number try to insert =11.1803398875, top vertex are coincident, i suppose Blender use a rounding in input UI
see T58730

You're saying using '=' and then a number changes things. I try it and if I inset faces with "=11.1" I get this:

The inset vertices are not in line with the original edges.

Germano Cavalcante (mano-wii) lowered the priority of this task from Needs Triage by Developer to Confirmed, Low.

Disabling the "Offset Relative" option and enabling "Edge Rail" seems to solve the problem.
I don't think it is worth confirming this bug since there are so many others bugs with higher priority to investigate;
you can work around the problem and
the initial result is very close to expected when done in other situations.

But I'll take a look anyway.

After investigating the code a bit, I realized that this is how Offset Relative works.
It was just coincidence that the edge length was close to the thickness limit.

I have to disagree. In all cases, no matter what settings are used, the resulting vertices should be on the existing faces.