bmesh.ops.bisect_plane()['geom_cut'] doesn't seem to include all the new edges #119980

New Issue

Anthony Aragues · 2024-03-27T20:08:37+01:00

Anthony Aragues commented

2024-03-27 20:08:37 +01:00

System Information
Operating system: macOS-14.2.1-x86_64-i386-64bit 64 Bits
Graphics card: Metal API AMD Radeon Pro 5500M 1.2

Blender Version
Broken: version: 4.1.0, branch: blender-v4.1-release, commit date: 2024-03-25 20:42, hash: 40a5e739e270
Worked: (newest version of Blender that worked as expected)

Short description of error
the ensure_lookup_table is not holding the indexes of geometry

Exact steps for others to reproduce the error
here's a test script, select a cube and run it

import bpy
import bmesh

def test_ensure_lookup_table(obj):
    # Create a new BMesh
    bm = bmesh.new()
    bm.from_mesh(obj.data)
    bm.edges.ensure_lookup_table()
    print('BEFORE')
    for edge in bm.edges:
        print(edge)
    objResults = bmesh.ops.bisect_plane(
            bm,
            geom=list(bm.verts) + list(bm.edges) + list(bm.faces),
            dist=0,
            plane_co=mathutils.Vector((0,0,0)),
            plane_no=(1,0,0),
            clear_inner=False,
            clear_outer=False)
    print('AFTER')
    for edge in bm.edges:
        print(edge)
    bm.to_mesh(obj.data)
    bm.free()

test_ensure_lookup_table(bpy.context.active_object)

you'll notice that everything after the 4th edge is moved. this is the exact behavior that function is supposed to prevent.
This issue is new to 4.1, was not in the 4.0 releases.

here's my results

BEFORE
<BMEdge(0x7fe2e0620010), index=0, verts=(0x7fe28a834080/2, 0x7fe28a834010/0)>
<BMEdge(0x7fe2e0620060), index=1, verts=(0x7fe28a834010/0, 0x7fe28a834048/1)>
<BMEdge(0x7fe2e06200b0), index=2, verts=(0x7fe28a834048/1, 0x7fe28a8340b8/3)>
<BMEdge(0x7fe2e0620100), index=3, verts=(0x7fe28a8340b8/3, 0x7fe28a834080/2)>
<BMEdge(0x7fe2e0620150), index=4, verts=(0x7fe28a834160/6, 0x7fe28a834080/2)>
<BMEdge(0x7fe2e06201a0), index=5, verts=(0x7fe28a8340b8/3, 0x7fe28a834198/7)>
<BMEdge(0x7fe2e06201f0), index=6, verts=(0x7fe28a834198/7, 0x7fe28a834160/6)>
<BMEdge(0x7fe2e0620240), index=7, verts=(0x7fe28a8340f0/4, 0x7fe28a834160/6)>
<BMEdge(0x7fe2e0620290), index=8, verts=(0x7fe28a834198/7, 0x7fe28a834128/5)>
<BMEdge(0x7fe2e06202e0), index=9, verts=(0x7fe28a834128/5, 0x7fe28a8340f0/4)>
<BMEdge(0x7fe2e0620330), index=10, verts=(0x7fe28a834010/0, 0x7fe28a8340f0/4)>
<BMEdge(0x7fe2e0620380), index=11, verts=(0x7fe28a834128/5, 0x7fe28a834048/1)>
AFTER
<BMEdge(0x7fe2e0620010), index=0, verts=(0x7fe28a834080/2, 0x7fe28a834010/0)>
<BMEdge(0x7fe2e0620060), index=1, verts=(0x7fe28a834010/0, 0x7fe28a834048/1)>
<BMEdge(0x7fe2e06200b0), index=2, verts=(0x7fe28a834048/1, 0x7fe28a8340b8/3)>
<BMEdge(0x7fe2e0620100), index=3, verts=(0x7fe28a8340b8/3, 0x7fe28a834080/2)>
<BMEdge(0x7fe2e0620150), index=4, verts=(0x7fe28a8341d0/8, 0x7fe28a834080/2)>
<BMEdge(0x7fe2e06201a0), index=5, verts=(0x7fe28a834208/9, 0x7fe28a834198/7)>
<BMEdge(0x7fe2e06201f0), index=6, verts=(0x7fe28a834198/7, 0x7fe28a834160/6)>
<BMEdge(0x7fe2e0620240), index=7, verts=(0x7fe28a8340f0/4, 0x7fe28a834160/6)>
<BMEdge(0x7fe2e0620290), index=8, verts=(0x7fe28a834198/7, 0x7fe28a834128/5)>
<BMEdge(0x7fe2e06202e0), index=9, verts=(0x7fe28a834128/5, 0x7fe28a8340f0/4)>
<BMEdge(0x7fe2e0620330), index=10, verts=(0x7fe28a834240/10, 0x7fe28a8340f0/4)>
<BMEdge(0x7fe2e0620380), index=11, verts=(0x7fe28a834278/11, 0x7fe28a834048/1)>
<BMEdge(0x7fe2e06203d0), index=12, verts=(0x7fe28a834160/6, 0x7fe28a8341d0/8)>
<BMEdge(0x7fe2e0620420), index=13, verts=(0x7fe28a8340b8/3, 0x7fe28a834208/9)>
<BMEdge(0x7fe2e0620470), index=14, verts=(0x7fe28a834010/0, 0x7fe28a834240/10)>
<BMEdge(0x7fe2e06204c0), index=15, verts=(0x7fe28a834128/5, 0x7fe28a834278/11)>
<BMEdge(0x7fe2e0620510), index=16, verts=(0x7fe28a834278/11, 0x7fe28a834240/10)>
<BMEdge(0x7fe2e0620560), index=17, verts=(0x7fe28a834208/9, 0x7fe28a834278/11)>
<BMEdge(0x7fe2e06205b0), index=18, verts=(0x7fe28a834208/9, 0x7fe28a8341d0/8)>
<BMEdge(0x7fe2e0620600), index=19, verts=(0x7fe28a8341d0/8, 0x7fe28a834240/10)>

**System Information** Operating system: macOS-14.2.1-x86_64-i386-64bit 64 Bits Graphics card: Metal API AMD Radeon Pro 5500M 1.2 **Blender Version** Broken: version: 4.1.0, branch: blender-v4.1-release, commit date: 2024-03-25 20:42, hash: `40a5e739e270` Worked: (newest version of Blender that worked as expected) **Short description of error** the ensure_lookup_table is not holding the indexes of geometry **Exact steps for others to reproduce the error** here's a test script, select a cube and run it ```python import bpy import bmesh def test_ensure_lookup_table(obj): # Create a new BMesh bm = bmesh.new() bm.from_mesh(obj.data) bm.edges.ensure_lookup_table() print('BEFORE') for edge in bm.edges: print(edge) objResults = bmesh.ops.bisect_plane( bm, geom=list(bm.verts) + list(bm.edges) + list(bm.faces), dist=0, plane_co=mathutils.Vector((0,0,0)), plane_no=(1,0,0), clear_inner=False, clear_outer=False) print('AFTER') for edge in bm.edges: print(edge) bm.to_mesh(obj.data) bm.free() test_ensure_lookup_table(bpy.context.active_object) ``` you'll notice that everything after the 4th edge is moved. this is the exact behavior that function is supposed to prevent. This issue is new to 4.1, was not in the 4.0 releases. here's my results BEFORE <BMEdge(0x7fe2e0620010), index=0, verts=(0x7fe28a834080/2, 0x7fe28a834010/0)> <BMEdge(0x7fe2e0620060), index=1, verts=(0x7fe28a834010/0, 0x7fe28a834048/1)> <BMEdge(0x7fe2e06200b0), index=2, verts=(0x7fe28a834048/1, 0x7fe28a8340b8/3)> <BMEdge(0x7fe2e0620100), index=3, verts=(0x7fe28a8340b8/3, 0x7fe28a834080/2)> <BMEdge(0x7fe2e0620150), index=4, verts=(0x7fe28a834160/6, 0x7fe28a834080/2)> <BMEdge(0x7fe2e06201a0), index=5, verts=(0x7fe28a8340b8/3, 0x7fe28a834198/7)> <BMEdge(0x7fe2e06201f0), index=6, verts=(0x7fe28a834198/7, 0x7fe28a834160/6)> <BMEdge(0x7fe2e0620240), index=7, verts=(0x7fe28a8340f0/4, 0x7fe28a834160/6)> <BMEdge(0x7fe2e0620290), index=8, verts=(0x7fe28a834198/7, 0x7fe28a834128/5)> <BMEdge(0x7fe2e06202e0), index=9, verts=(0x7fe28a834128/5, 0x7fe28a8340f0/4)> <BMEdge(0x7fe2e0620330), index=10, verts=(0x7fe28a834010/0, 0x7fe28a8340f0/4)> <BMEdge(0x7fe2e0620380), index=11, verts=(0x7fe28a834128/5, 0x7fe28a834048/1)> AFTER <BMEdge(0x7fe2e0620010), index=0, verts=(0x7fe28a834080/2, 0x7fe28a834010/0)> <BMEdge(0x7fe2e0620060), index=1, verts=(0x7fe28a834010/0, 0x7fe28a834048/1)> <BMEdge(0x7fe2e06200b0), index=2, verts=(0x7fe28a834048/1, 0x7fe28a8340b8/3)> <BMEdge(0x7fe2e0620100), index=3, verts=(0x7fe28a8340b8/3, 0x7fe28a834080/2)> <BMEdge(0x7fe2e0620150), index=4, verts=(0x7fe28a8341d0/8, 0x7fe28a834080/2)> <BMEdge(0x7fe2e06201a0), index=5, verts=(0x7fe28a834208/9, 0x7fe28a834198/7)> <BMEdge(0x7fe2e06201f0), index=6, verts=(0x7fe28a834198/7, 0x7fe28a834160/6)> <BMEdge(0x7fe2e0620240), index=7, verts=(0x7fe28a8340f0/4, 0x7fe28a834160/6)> <BMEdge(0x7fe2e0620290), index=8, verts=(0x7fe28a834198/7, 0x7fe28a834128/5)> <BMEdge(0x7fe2e06202e0), index=9, verts=(0x7fe28a834128/5, 0x7fe28a8340f0/4)> <BMEdge(0x7fe2e0620330), index=10, verts=(0x7fe28a834240/10, 0x7fe28a8340f0/4)> <BMEdge(0x7fe2e0620380), index=11, verts=(0x7fe28a834278/11, 0x7fe28a834048/1)> <BMEdge(0x7fe2e06203d0), index=12, verts=(0x7fe28a834160/6, 0x7fe28a8341d0/8)> <BMEdge(0x7fe2e0620420), index=13, verts=(0x7fe28a8340b8/3, 0x7fe28a834208/9)> <BMEdge(0x7fe2e0620470), index=14, verts=(0x7fe28a834010/0, 0x7fe28a834240/10)> <BMEdge(0x7fe2e06204c0), index=15, verts=(0x7fe28a834128/5, 0x7fe28a834278/11)> <BMEdge(0x7fe2e0620510), index=16, verts=(0x7fe28a834278/11, 0x7fe28a834240/10)> <BMEdge(0x7fe2e0620560), index=17, verts=(0x7fe28a834208/9, 0x7fe28a834278/11)> <BMEdge(0x7fe2e06205b0), index=18, verts=(0x7fe28a834208/9, 0x7fe28a8341d0/8)> <BMEdge(0x7fe2e0620600), index=19, verts=(0x7fe28a8341d0/8, 0x7fe28a834240/10)>

Anthony Aragues added the

labels 2024-03-27 20:08:37 +01:00

YimingWu commented

2024-03-28 03:59:46 +01:00

I'm not sure I understood the part where everything after the 4th edge is moved. From my test, 4.0~4.2 all give similar printed result, and the geometry is correctly bisected. Could you clarify the difference you see and what is the result you are expecting?

I'm not sure I understood the part where `everything after the 4th edge is moved`. From my test, 4.0~4.2 all give similar printed result, and the geometry is correctly bisected. Could you clarify the difference you see and what is the result you are expecting?

YimingWu added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2024-03-28 04:00:01 +01:00

Anthony Aragues commented

2024-03-28 15:39:32 +01:00

yes. I may be reading this wrong. There is certainly a difference between 4.0 and 4.1 for me in this area but it may have more to do with the bisect plane?

in 4.0, I can run multiple bisect planes and each one will select the the geo_cut then loop where I grab the edges selected and bisect again.

in 3.6->4.0 it goers through all the cuts fine. In 4.1 it can't find the some of the selected edges to add to the geo list for bisect plane .

previously when I had this same exact issue it's because I needed to ensure the lookup table.

This time I'm not sure, I bypassed this for now by looping through geo returned from bisect plane instead of geo_cut and filtered by edges to select them, and that works for me...

so something certainly changed and I can workaround it.

I apologize if I mis diagnosed the function that has the issue

yes. I may be reading this wrong. There is certainly a difference between 4.0 and 4.1 for me in this area but it may have more to do with the bisect plane? in 4.0, I can run multiple bisect planes and each one will select the the geo_cut then loop where I grab the edges selected and bisect again. in 3.6->4.0 it goers through all the cuts fine. In 4.1 it can't find the some of the selected edges to add to the geo list for bisect plane . previously when I had this same exact issue it's because I needed to ensure the lookup table. This time I'm not sure, I bypassed this for now by looping through geo returned from bisect plane instead of geo_cut and filtered by edges to select them, and that works for me... so something certainly changed and I can workaround it. I apologize if I mis diagnosed the function that has the issue

YimingWu commented

2024-03-29 08:45:17 +01:00

@Anthong The order of geometry indices should not be expected to stay the same after any topology operations if that's what the can't find the some of the selected edges part was about.

However the function should always ensure a valid table for lookup, so do you have what exactly you are expecting it to return? In what format or order?

@Anthong The order of geometry indices should not be expected to stay the same after any topology operations if that's what the `can't find the some of the selected edges` part was about. However the function should always ensure a valid table for lookup, so do you have what exactly you are expecting it to return? In what format or order?

Anthony Aragues commented

2024-03-29 15:25:13 +01:00

I have a new example script that shows the exact issue I ran into. I tested in 4.0.2 vs 4.1

import bpy
import bmesh
import mathutils

def test(obj):
    # Create a new BMesh
    bm = bmesh.new()
    bm.from_mesh(obj.data)
    bm.edges.ensure_lookup_table()
    for edge in bm.edges:
        print(edge)
    objResults = bmesh.ops.bisect_plane(
            bm,
            geom=list(bm.verts) + list(bm.edges) + list(bm.faces),
            dist=0,
            plane_co=mathutils.Vector((0,0,0)),
            plane_no=(1,0,0),
            clear_inner=False,
            clear_outer=False)
    for objGeo in objResults['geom_cut']:
        objGeo.select = True
        
    arrEdges = [e for e in bm.edges if e.select]
    bmesh.ops.bisect_plane(
            bm,
            geom=list(bm.verts) + arrEdges + list(bm.faces),
            dist=0,
            plane_co=mathutils.Vector((0.5,0.5,0.5)),
            plane_no=(1,0,0),
            clear_inner=False,
            clear_outer=False)
    
    bm.to_mesh(obj.data)
    bm.free()

test(bpy.context.active_object)

the second bisect plane doesnt work in 4.1 because the geometry isnt selected.

so this might be a difference in the return output of bisect_plane?

I did find a workaround to this. but this is a change that wasnt in the changelog.

let me know if you'd like me to create a separate bug.

I have a new example script that shows the exact issue I ran into. I tested in 4.0.2 vs 4.1 ```python import bpy import bmesh import mathutils def test(obj): # Create a new BMesh bm = bmesh.new() bm.from_mesh(obj.data) bm.edges.ensure_lookup_table() for edge in bm.edges: print(edge) objResults = bmesh.ops.bisect_plane( bm, geom=list(bm.verts) + list(bm.edges) + list(bm.faces), dist=0, plane_co=mathutils.Vector((0,0,0)), plane_no=(1,0,0), clear_inner=False, clear_outer=False) for objGeo in objResults['geom_cut']: objGeo.select = True arrEdges = [e for e in bm.edges if e.select] bmesh.ops.bisect_plane( bm, geom=list(bm.verts) + arrEdges + list(bm.faces), dist=0, plane_co=mathutils.Vector((0.5,0.5,0.5)), plane_no=(1,0,0), clear_inner=False, clear_outer=False) bm.to_mesh(obj.data) bm.free() test(bpy.context.active_object) ``` the second bisect plane doesnt work in 4.1 because the geometry isnt selected. so this might be a difference in the return output of bisect_plane? I did find a workaround to this. but this is a change that wasnt in the changelog. let me know if you'd like me to create a separate bug.

Screenshot 2024-03-29 at 10.21.26 AM.png

247 KiB

Screenshot 2024-03-29 at 10.18.23 AM.png

164 KiB

Screenshot 2024-03-29 at 10.21.26 AM.png

Screenshot 2024-03-29 at 10.18.23 AM.png

Anthony Aragues closed this issue

2024-03-29 15:25:17 +01:00

Blender Bot added

Status

Archived

and removed

Status

Needs Information from User

labels 2024-03-29 15:25:19 +01:00

Anthony Aragues reopened this issue

2024-03-29 15:25:28 +01:00

Blender Bot added

and removed

labels 2024-03-29 15:25:30 +01:00

Anthony Aragues commented

2024-03-29 15:25:46 +01:00

sorry, closed by accident

Anthony Aragues closed this issue

2024-03-29 15:25:52 +01:00

Blender Bot added

and removed

labels 2024-03-29 15:25:54 +01:00

Anthony Aragues reopened this issue

2024-03-29 15:25:59 +01:00

Blender Bot added

and removed

labels 2024-03-29 15:26:02 +01:00

YimingWu commented

2024-03-29 15:47:32 +01:00

I see, this is indeed a bit different. Can confirm the issue.

~~There seem to be one commit of interest recently, dcb2c0bdf6, let me test it~~ Edit: this is not the breaking commit. Need bisecting.

I see, this is indeed a bit different. Can confirm the issue. <s>There seem to be one commit of interest recently, dcb2c0bdf673b783c119c4912e1dc6, let me test it</s> Edit: this is not the breaking commit. Need bisecting.

YimingWu added

and removed

labels 2024-03-29 15:47:51 +01:00

YimingWu added

and removed

labels 2024-03-29 15:57:37 +01:00

YimingWu changed title from ~~bmesh ensure_lookup_table appears to be broken~~ to `bmesh.ops.bisect_plane()['geom_cut']` doesn't seem to include all the new edges

2024-03-29 16:00:19 +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

bmesh.ops.bisect_plane()['geom_cut'] doesn't seem to include all the new edges #119980

`bmesh.ops.bisect_plane()['geom_cut']` doesn't seem to include all the new edges #119980