mathutils.geometry.points_in_planes: hardcoded precision set too high #120862

New Issue

Closed

opened 2024-04-20 20:15:18 +02:00 by Dmitry C. · 3 comments

Dmitry C. commented

2024-04-20 20:15:18 +02:00

System: Windows 10
Broken: Blender 2.79 - 4.1.1
Worked: never?

Short description of error
The operation returns all points of intersection for given planes.

The epsilon for checking if a vertex lies on a plane is too small, which often leads to the planes cutting off their own verts if more than three planes meet at the same point.

I'm attaching a .blend file (2.79) with text editor script that illustrates the problem and contrasts the behavior with the same function ported to python (with custom precision).

Notably, Blender versions prior to 2.9 seem to have even worse issues than the current 4.1. I'm guessing the face normals were made more accurate between 2.8 and 2.9.

It seems like the operation was custom-made for the Cell Fracture addon (in Blender 2.64). The addon uses it to generate random cells for cutting into a mesh, so a lost vert here and there doesn't matter much. For other applications, the precision not being exposed renders the operation practically unusable.

Additionally, unrelated to this operation, the Cell Fracture addon makes heavy use of booleans which default to "Exact" solver without "Self Intersection". This leads to missing chunks on more complex meshes (for example, the Blender demo basemeshes). Switching to "Fast" solver would improve both performance and reliability. A single line fix.

System: Windows 10 Broken: Blender 2.79 - 4.1.1 Worked: never? **Short description of error** The operation returns all points of intersection for given planes. The epsilon for checking if a vertex lies on a plane is too small, which often leads to the planes cutting off their own verts if more than three planes meet at the same point. I'm attaching a .blend file (2.79) with text editor script that illustrates the problem and contrasts the behavior with the same function ported to python (with custom precision). Notably, Blender versions prior to 2.9 seem to have even worse issues than the current 4.1. I'm guessing the face normals were made more accurate between 2.8 and 2.9. It seems like the operation was custom-made for the Cell Fracture addon (in Blender 2.64). The addon uses it to generate random cells for cutting into a mesh, so a lost vert here and there doesn't matter much. For other applications, the precision not being exposed renders the operation practically unusable. Additionally, unrelated to this operation, the Cell Fracture addon makes heavy use of booleans which default to "Exact" solver without "Self Intersection". This leads to missing chunks on more complex meshes (for example, the Blender demo basemeshes). Switching to "Fast" solver would improve both performance and reliability. A single line fix.

isect_demo.blend

60 KiB

isect_pic.png

136 KiB

Dmitry C. added the

labels 2024-04-20 20:15:18 +02:00

Iliya Katushenock added the

label 2024-04-20 20:17:29 +02:00

YimingWu commented

2024-04-22 04:46:25 +02:00

Member

Can confirm. It does seem that this kind of epsilon values has to be tuned for individual usages and not a one-value-fits-all. And thank you very much for the detailed script for reproduction 👍

Looks like M_Geometry_points_in_planes is already VA_ARG... Might need a new function that takes thresholds first (or everything as named variables)? This way we can keep old code working and supply custom thresholds as needed. I could take a look on how to achieve this. cc @JacquesLucke @ideasman42

Can confirm. It does seem that this kind of epsilon values has to be tuned for individual usages and not a one-value-fits-all. And thank you very much for the detailed script for reproduction 👍 Looks like `M_Geometry_points_in_planes` is already VA_ARG... Might need a new function that takes thresholds first (or everything as named variables)? This way we can keep old code working and supply custom thresholds as needed. I could take a look on how to achieve this. cc @JacquesLucke @ideasman42

YimingWu added

and removed

labels 2024-04-22 04:46:39 +02:00

Campbell Barton commented

2024-04-22 05:26:29 +02:00

Owner

Planes is only a single argument, so having two optional epsilon arguments seems reasonable.

Planes is only a single argument, so having two optional epsilon arguments seems reasonable.

YimingWu commented

2024-04-22 05:30:46 +02:00

Member

Oh I see it's a single argument of a list. I guess I could add some named arguments too.

Oh I see it's a single argument of a list. I guess I could add some named arguments too.

YimingWu referenced a pull request that will close this issue

2024-04-22 07:31:06 +02:00

Fix #120862: Add eps arguments to points_in_planes #120910

YimingWu referenced this issue from a commit

2024-04-24 09:38:33 +02:00

Fix #120862: Add eps arguments to points_in_planes

YimingWu closed this issue

2024-04-24 09:38:34 +02:00

Blender Bot added

and removed

labels 2024-04-24 09:38:36 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#120862

No description provided.