2020-12-15 - Tuesday Talks - Module Meetings

Meetings
1

Tuesday Talks

Notes for module meetings of Tuesday, 15 December 2020.
Present: Dalai Felinto (all)

General Topics

  • No more meeting until January 12, 2021.

Modeling

Participant: Campbell Barton.

  • Initial task for tools polishing todos
    • Campbell will present that in the next UI meeting.
    • The keymap related tools are a topic on its own, and so are knife fixes, grease pencil UI re-organization, …
    • This is a good candidate for a “team” approach.
  • The module at the moment has very little community involvement.

Nodes & Physics

Participant: Sebastián Barschkis.

  • Sebastián plan was to finish viscosity for 2.92.
  • For January the goal is to present either a prototype for real-time (interactive) fluids or a design doc with a plan of attack

User Interface

Participant: Julian Eisel.

  • Asset browser to be merged later today.
  • In its current capacity the UI team is focusing mostly on patch review.
  • Besides helping with 1 or 2 projects such as the asset browser or the nodes.

Sculpt, Paint, Texture

Participant: Pablo Dobarro.

  • Dynamic topology refactor doesn’t seem to be ready for bcon2, thus it will need to be postposed.
  • temp_bmesh_multires branch has a few different features in different states:
    • bmesh dynamically topology - works
    • Face sets dyntopo support
      • Render, but operator doesn’t work
    • bmesh multires: unknown
    • tools for sharpening vertex colors
  • The bmesh dyntopo is the priority within the branch
    • It should be isolated and set to review separately
    • It needs to be properly reviewed
    • Pablo to check Joseph’s availibility and plan

Animation & Rigging

Participant: Sybren Stüvel.

  • The animation module is progressing
  • The new contributors are cross-patch reviewing.
  • That leaves more time for Sybren to coordinate with Luciano and Bassam new targets for the module.

VFX & Video

Participant: Richard Antalík.

  • VSE milestone 1 reviewed started.
    • Francesco gave a first pass, which Richard already addressed.
    • Waiting for Francesco’s final review.
    • It can be committed after bcon1
  • VSE: Render preview improvement awaits review
    • Richard is waiting for Francesco test file.
  • Richard will be able to work fulltime in VSE development starting next year

Data, Assets & I/O

Participant: Bastien Montagne.

  • Overrides update:
    • Storage performance is now in master.
    • Materials, nodetrees and RNA collection are the main remaining targets
  • USD importer is not a target for 2.92.

Grease Pencil

Participant: Antonio Vazquez (via chat).

  • I/O features won’t make into 2.92
    • The discussion about Libharu is still on going
    • Final implementation will still need to be patch reviewed
    • Antonio still would like to have it integrated as soon as possible for 2.93 to give it for testing and polishing
  • The layer transform will also be for 2.93
    • The patch is ready to merge in master but it will wait until 2.93 bcon1
  • An improved interpolate is coming too
    • This is the final planned 2.92 feature.

Rendering

The rendering topics are handled in a separate meeting that includes the Cycles and EEVEE modules.

8 Likes
2

Too bad the Dyntopo refactor needs to be postponed, but I’m very glad to see that Dyntopo is getting the necessary attention and priority. :+1:

3

so glad to see this as the industry is taking the path of real time and interactivity using GPUs power.

@dfelinto @sybren what happened to the plan of ‘fixing’ alembic importer ?

4

@pablodp606 @dfelinto @ideasman42 With all this work being done on dynamic topology and the related work on the BMesh module, and as someone who is currently working with the Python API of BMesh to develop an addon where performance is critical, may I request your consideration for a couple of things:

BMesh Duplicate and Split operators aren’t fully implemented: For BMesh, the operators for duplicate and split have functionality that is documented in the API manual but which no one has ever implemented. They are meant to offer the option to duplicate or split a section of geom into another bmesh but this has never been implemented. As it currently stands the only way to split a section of a BMesh into another BMesh right now is to manually create a new BMesh and create the new faces/verts from scratch by copying the values you want from the existing BMesh. This is a very slow operation in Python, so having these operators fully implemented would be a godsend.

BMesh Bisect Box operator: Right now one of the tasks my addon must perform is cutting out a slice of geometry in the form of a bounding box from several joined meshes. I’ve been doing this with the bisect_plane function to perform the operation 6 times, one for each side of the box, but it seems wasteful of CPU cycles, each time it’s looping over all the geometry from scratch. I’d wager a bisect_box operator could be substantially faster, considering all the geometry once and doing the bisects in one go. Thoughts?

BMesh UVProject operator: Currently the only means of doing any kind of UV projection with BMesh is via loops in python, looking through faces/loops, setting values manually, which is very slow, slow enough to leave Blender hanging for 30 seconds on a large 100k poly mesh on even a fast PC. I would absolutely love a UV project operator for BMesh. In comparison the UVProject modifier in Blender is almost real time even with a 500k vert mesh. Having some kind of UVProject operator for BMesh would be a godsend. Something as simple as just a flat projection of verts from a particular orthogonal direction, with scale, rotation and translation parameters, would obliterate one bottleneck in my addon.

Or, to achieve the same outcome in my case with probably even less code, a simple modification to the UVProject modifier to allow an object to use itself as a projector would work too.

I’m considering just using the UVProject modifier with an invisible empty parented to each object, and doing some logic to ensure empties are created and deleted automatically, but it seems like a messy solution. If I knew my way around the code for the UVProject modifier I’d offer to make the change myself. If someone wants to explain to me what’s needed I’d be happy to do it.

BVH from Mesh: I’m experimenting with accelerating sections of my code with the BVH, but I notice there’s only an option to create a BVH from either a BMesh or Object. Is there any reason why we couldn’t have an option to create a BVH from a mesh directly? It would just be a nice convenience.

I know everything is possible with enough coding in Python and I’m currently trying everything I can to squeeze out more performance, but having some of this stuff available as an operator would be wonderful and really help out. Thanks for reading!

1 Like
5
3 Likes
6

@ideasman42 what’s the status about the hi-poly editing improvements?

Link to the thread, don’t want to clutter here:

2 Likes