Boolean works not badly - multiprecision/float round trips #83136

New Issue

vinh · 2020-11-28T01:33:56+01:00

vinh commented

2020-11-28 01:33:56 +01:00

System Information
Operating system: Windows 10 64BIT version 20H2
Graphics card: Built-in NVIDIA GEFORCE 820M

Blender Version
blender-2.91.0-31bf8307afc0-windows64

Short description of error

Boolean (exact) works not good. There are some remained faces
CLOCK ENGINE HOUSE.blend

Please see attached image and .blend file.

**System Information** Operating system: Windows 10 64BIT version 20H2 Graphics card: Built-in NVIDIA GEFORCE 820M **Blender Version** blender-2.91.0-31bf8307afc0-windows64 **Short description of error** Boolean (exact) works not good. There are some remained faces [CLOCK ENGINE HOUSE.blend](https://archive.blender.org/developer/F9393825/CLOCK_ENGINE_HOUSE.blend) ![blender - boolean not good.png](https://archive.blender.org/developer/F9393837/blender_-_boolean_not_good.png) Please see attached image and .blend file.

vinh commented

2020-11-28 01:33:56 +01:00

Added subscriber: @qvinh222

AnityEx commented

2020-11-28 02:40:38 +01:00

Added subscriber: @AnityEx

AnityEx commented

2020-11-28 02:40:38 +01:00

Try recalculating normals beforehand (shift+n in edit mode)

Howard Trickey commented

2020-11-28 14:37:45 +01:00

Added subscriber: @howardt

Howard Trickey commented

2020-11-28 14:37:45 +01:00

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

Howard Trickey closed this issue

2020-11-28 14:37:45 +01:00

Howard Trickey commented

2020-11-28 14:37:45 +01:00

The problem here is different trips in and out of floating point, with different transformation matrices, lead to coordinates that should logically be the same in fact having very slightly different values. In this example, the cylinders are subtracted from the Cube, leaving some cylinder-derived coordinates on the resulting mesh. Then the cube-minus-cylinders thing is subtracted from the big cylinder (Cylinder005), leaving more cylinder-derived coordinates on the big cylinder. The finally, the original cylinders are subtracted from that last result -- the user expects that the cylinder-derived coordinates will exactly line up with the corresponding ones on the original cylinders. This is not an unreasonable expectation.

But: because each individual modifier ends by going back into floating point coordinates, it is not guaranteed that that expectation will be true.

This is a known limitation, so I am marking this as Invalid. Sorry, Invalid seems harsh here, but there is not a "Known Limitation" status.

The only way I can think of to fix this limitation is to do all modifier calculations in exact arithmetic, passing the exact-arithmetic result of one modifier to the others that use that result. This would require major surgery on the way modifier stacks work in Blender, and unlikely to be done any time soon, if ever. Maybe the move to "everything nodes" could allow for a new type of geometry pass-through, "exact geometry", that could solve this problem.

The problem here is different trips in and out of floating point, with different transformation matrices, lead to coordinates that should logically be the same in fact having very slightly different values. In this example, the cylinders are subtracted from the Cube, leaving some cylinder-derived coordinates on the resulting mesh. Then the cube-minus-cylinders thing is subtracted from the big cylinder (Cylinder005), leaving more cylinder-derived coordinates on the big cylinder. The finally, the original cylinders are subtracted from that last result -- the user expects that the cylinder-derived coordinates will exactly line up with the corresponding ones on the original cylinders. This is not an unreasonable expectation. But: because each individual modifier ends by going back into floating point coordinates, it is not guaranteed that that expectation will be true. This is a known limitation, so I am marking this as Invalid. Sorry, Invalid seems harsh here, but there is not a "Known Limitation" status. The only way I can think of to fix this limitation is to do all modifier calculations in exact arithmetic, passing the exact-arithmetic result of one modifier to the others that use that result. This would require major surgery on the way modifier stacks work in Blender, and unlikely to be done any time soon, if ever. Maybe the move to "everything nodes" could allow for a new type of geometry pass-through, "exact geometry", that could solve this problem.

Howard Trickey changed title from ~~Boolean works not badly~~ to Boolean works not badly - multiprecision/float round trips

2021-02-07 15:03:02 +01: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

Boolean works not badly - multiprecision/float round trips #83136