2024-06-10 Sculpt, Paint, & Texture Project Meeting

Project kickoff meeting to discuss topics specific to the current sculpting project, in addition to the regular module meetings. Check the overview thread for all meeting notes.

Present

  • Raul Fernandez Hernandez
  • Sean Kim
  • Sergey Sharybin
  • Hans Goudey

Since the Last Meeting

  • Landed: Sculpt: Start data-oriented refactor for draw brush #121835
    • Some side effects for sculpting on deformed meshes were fixed after the initial merge.

Meeting Topics

  • Needs review: Sculpt: Initial data-oriented refactor for smooth brush #122906
  • Sculpt brush refactor planning
    • Sean can start working on the mask brush next. He could also work on the smooth mask brush after that.
    • Raul can start with the draw sharp brush.
    • Hans will do the scrape brush next.
  • Refactor process
    • We’ll continue adding files one at a time unless there’s a reason to do it a different way.
    • There will be lots of code duplication for the forseable future. That’s partially a good thing to reduce confusing link between brush implementations.
    • We can make a feedback thread for the refactor as a place to post updates and push people to do testing of the latest builds.
  • Time division between multires improvements and “sculpt brush refactor”
    • With both Sean and Raul working on the project grant, we may have the opportunity to combine multires improvements/fixing with the refactors discussed above, and do more work in parallel. But just diving into the refactors would be okay too.
      • Long standing issues like “spikes” might be smaller issues in the algorithm (though hard to find). They might also be fundamental issues though. Research is needed in that area.
      • First we’ll focus on researching to find out which issues are larger and fundamental, or smaller shorter term issues. That will infuence larger decisions down the line about which path to go with multires concepts and data structures in general.
  • Technical dissussion about sculpt normals update
    • Currently it happens during redraw, this is problematic when no redraw happens between multiple brush samples, like for curve-type strokes.
    • An alternative would be recalculating normals before every brush sample. But this probably isn’t better for performance where the one-at-a-time sampling is just an implementation detail.
  • Technical discussion about BVH layout
    • A full AoS data structure is probably not best for performance. That’s something to keep in mind when designing the replacement data structures.
18 Likes

no pressure, but about the brush refactor line-up, i’d expect the grab brush to be the next guy on the list (after the draw and smooth). u know, going from the most used brushes to the less ones :smiley:

1 Like

We’re generally working from least to most complex actually. How much they’re used doesn’t really factor in, since we should have them all done for the next release anyway.

10 Likes

One question:
will you take into consideration the Call for Content: Default Brushes or it is out of the scope of the refactor?

2 Likes

That’s mainly a separate project-- the work is on the design-side rather than being mainly a technical issue.

2 Likes

Although it may not be appropriate to share here, I really want to convey this message.
I hope you also consider this aspect while delving into the fundamental data structures.
It’s an essential part that’s greatly needed across various sectors of the industry.

3 Likes