2024-05-30 Modeling Module Meeting

Meetings
1

First of regular meetings with newly expanded Artist Members

Day and Time: 2024-05-30T21:00:00Z
Meeting Link

Present:

  • Howard Trickey
  • Campbell Barton
  • Hans Goudy
  • Jonathan Lampel
  • Nika Kutsniashvili

Agenda:

  • Introductions
  • Current Projects - Status
    • Howard: Working on new Robust Boolean geometry node and modifier based on Manifold Library
      • Given manifold input, will always give manifold output
      • Currently have it working for triangulated output and face attributes only.
      • Timing on 650k face example:
        • Float: 407 ms
        • Exact: 1309 ms
        • Manifold: 282 ms
      • Now part way through code to de-triangulate and propagate vert/edge/corner attributes
    • Campbell: Looking at a different triangulation algorithm to scanfill. Needs are different than what a rendering engine needs. Has a working one based on monotonic scans.
    • Hans: refactoring drawing mode for meshes (more modern how it is sent to gpu): three to four times faster in tests (better outside of edit mode)
    • Nick: made code for images as planes - for drag and drop. Will maybe send a PR soon.
  • What to do for code quality project:
    • We looked at the 7 high priority bug reports and some of the 634 open bug reports.
    • Howard classified the 100 most recent bug reports.
      • no huge pattern, though UV, boolean, normals, and snapping seem popular
      • artist view: uv and snapping seem important
      • also: knife and shear and other real edit operation bugs should get some attention
      • many are not technically bugs but remain open because we could do better and/or need to document the current behavior better
      • maybe 15% are actually better classified as bugs for other modules
      • good code quality project would be to aim to reduce some of these
  • Info from developers requested on bugs
    • Should BMesh be allowed to create 2 faces identical except normals reversed? bug
      • we should not allow these
    • How should we treat bug reports re floating point issues? bug
      • should we bend over far backwards to deal with these?
      • some UI changes over the years have helped hide some of these issues
      • canned answer? nice to have something to link to with “here are some typical problems”, and maybe wikipedia is not enough. Every floating point problem is not necessarily a bug, but some may be.
      • question: do users just not like the look of things not being what they’d expect if exact math where used, or is it preventing them from doing things they want to do?
        • answer: mix of both. More often it is just an aesthetic / clash of expectation thing; but sometimes (say, where there’s a huge range of scale in the scene, or there is some reliance on exact coplanarity) it makes it hard to accomplish what the user wants
      • could use doubles for transforms only, but that won’t help if same mesh has huge scale
      • other applications store coordinates in doubles, which makes transfer to and from Blender look bad
    • Are there expectations on how UV unwrap should work re orthogonality to axes? bug
      • probably should be regarded as a bug. We didn’t use to guarantee same results over versions since it is just an operator, but now it is a geometry node…
    • Should Add Arc (extra object addon) add one to the number of sides? bug
      • should probably be fixed
    • How to show transform space in nested situation? bug
      • maybe this is not so much a modeling thing? doesn’t seem like a large
  • Next meeting?
    • Try for cadence of every two weeks, alternating which time zone is favored
    • Proposed Next meeting: 2024-06-17T12:00:00Z
23 Likes
2

One area where floating point imprecision especially gets in the way is using the edit mode Add Cube operator for boolean cuts. There is basically a 50% chance it will not work properly, making the workflow completely unviable.

3

This is using the float boolean solver, right? If so, I would not term it so much a “floating point issue” (in the sense we were discussing in the meeting), but rather a deliberate choice to to handle the coplanar case when developing that code.

4

This is the exact solver, it’s the default for the Intersect (Boolean) operator. The issue is that the Add Cube operator I’m using in the video cannot always place the cube on the mesh correctly, presumably due to floating point precision. It’s always small enough that the UI displays the vertex positon as an integer, but big enough that the boolean doesn’t consider it coplanar. I’m bringing this up here because it seems to fall into “won’t fix” according to recent discussions.

1 Like
5

Ah, got it. So you are correct.