2021-05-25 Blender Rendering Meeting

Meetings
1

Attendees

  • Brecht Van Lommel (Blender)
  • Jeroen Bakker (Blender)
  • Kévin Dietrich (Blender)
  • Patrick Mours (NVIDIA)
  • Edoardo Dominici (Tangent)
  • Sergen Eren (Tangent)

Notes

Release Status

  • No high priority bugs remaining for 2.93, so no code changes expected at this point.
  • 3.0 release is likely to move a few months later, so Cycles X might be ready in time for that.

Cycles

  • Cycles X: main new development is removal of the megakernel and some further GPU performance optimizations. This also reduces OptiX runtime compilation time to less than a second, as only the simple intersection kernels need to be compiled. Main focus this week is to bring back some features like shader ray-tracing and baking.
  • Sergen worked on adding indirect light in his delta tracking implementation.
  • Edoardo was looking into transparency efficiency for point cloud rendering, perhaps doing shading in the intersection function and ensuring good sample stratification.
  • Kévin is finishing various patches for the Alembic procedural and OptiX BVH performance.

Eevee & Viewport

  • Jeroen works on mesh drawing performance for mesh editing, together with other developers as part of a mesh editing performance project announced on code.blender.org.
  • Kévin is rewriting his initial code for OpenSubdiv support on the GPU. The batch cache for OpenSubdiv needs to be different than for regular meshes to preserve all the required connectivity, so this involves a fair amount of work to add a new batch cache backend.

Practical Info

This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.

For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.

  • Agenda
  • Google Meet
  • Time: Tuesday 5 to 6 PM Amsterdam Time
  • Next Meeting: June 1, 2021
11 Likes
2

Hmm, would this allow us to reuse the OSD evaluator for modifiers (or other mesh operations) after the Subdivision modifier?
(As I’m guessing that the OSD data is not sent to the GPU during the modifier evaluation)

I’m asking as I’ve wanted to do this in the past when using/querying data from the subdivision limit surface. Currently I have to recreate the evaluator by feeding it the mesh data again. And this process is quite slow, so if this already has been done once for the mesh, it would be very nice to be able to reuse it.

3

That’s not really specific to evaluating OpenSubdiv on the CPU as part of the modifier stack or on the GPU as far as I know. If the OpenSubdiv data structures need to be kept around and accessible that’s possible in either case.

That being said, I think in many cases using the limit surface is not that helpful. For selection, collision, hair distribution, … it can be problematic to have a disconnect with the actual mesh surface, or needlessly expensive.

1 Like
4

Right, my use case is very specific: https://www.labri.fr/perso/pbenard/publications/contours/

In that paper you need the limit surface to be able to tessellate the mesh properly (to compute the “true” contour line on the mesh).