Developer Meeting Notes

[razin (NizarAmous)]

@MichaelBenDavid

just 4 duh??

that means less dev time spent on reviewing code

[TheRedWaxPolice (I know dead mesh when I see it..)]

2022-05-24 Render & Cycles Meeting

Attendees

• Brecht Van Lommel (Blender)
• Patrick Mours (NVIDIA)
• Christophe Hery (Facebook)
• Olivier Maury (Facebook)
• Brian Savery (AMD)
• Stefan Werner (Intel)

Announcements

• The original intent of this meeting was to cover both the Render & Cycles and Eevee & Viewport modules, but in practice it was mostly about Cycles. We’ve now made that official, with the addition of a separate Eevee & Viewport module meeting .

Planning

• The main Blender 3.2 high priority bugs are related to ray-tracing. Brecht is working on solutions but it’s difficult, unclear how much we can fix before the release.
• AMD HIP status:
  • Linux RDNA2 support appears to be stable for the 3.2 release.
  • Linux RDNA1 support has a critical bug with image textures. This is being investigated, hopefully fixed for 3.2 but uncertain at this point.
  • Windows and Linux Vega support is aimed at 3.3.
  • Hardware ray-tracing support is aimed at 3.4 or earlier.
  • On Windows, the HIP SDK needs to be upgraded for compatibility with AMD drivers. Brecht will do this upgrade for 3.2. Old drivers should also work with this new HIP SDK, however old Blender versions may not work with new AMD drivers.
• MNEE: there are some known limitations in the method still, none planned to be fixed for the 3.2 release. As a reminder, MNEE is not a general caustics solution, though some limitations may be solved still.
• NanoVDB: Patrick added support for rendering half float and variable precision, which helps significantly reduce volume memory usage. Half float is enabled by default and generally renders the same as full float. Variable precision seems to lose more detail than expected, needs to be investigated why.
• Intel OneAPI: work continues to make this ready for integration in an official release. Currently work is ongoing on setting up automated building of the required LLVM forks and other dependencies.
• Intel OpenImageDenoise recently gained GPU supported, that should also work on NVIDIA, AMD and Apple devices. Stefan started prototyping an implementation in Cycles. Quality is identical to CPU denoising with improved performance, so this looks very promising.
• Principled BSDF: Lukas is investigating an upgrade to the Principled BSDF, adding more features and solving some long standing issues. A task with a plan for this will be created. There are many things to balance: usability, production vs. game engines, compatibility with other apps and file formats. The first step is to replace the multiscatter GGX with a regular GGX that uses albedo scaling for energy conservation, which should be faster and reduce noise.

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
• Google Calendar Event
• Next Meeting: June 7, 2022, 5 to 6 PM Amsterdam Time (Your local time: June 7, 2022 4:00 PM → June 7, 2022 5:00 PM )

2022-05-24 Render & Cycles Meeting

[Metin_Seven]

@TheRedWaxPolice

Principled BSDF: Lukas is investigating an upgrade to the Principled BSDF, adding more features and solving some long standing issues. A task with a plan for this will be created. There are many things to balance: usability, production vs. game engines, compatibility with other apps and file formats. The first step is to replace the multiscatter GGX with a regular GGX that uses albedo scaling for energy conservation, which should be faster and reduce noise.

Nice!

@Kologe

Curves

• Use only current brush location for delete brush (commit ) (Hans Goudey)
• Support pressure in sculpt brushes (commit ) (Hans Goudey)

Does anyone know if the new curves hair engine adapts vertex colors from the source mesh?

[Ace_Dragon]

If the new GGX shading is visually similar to the multiscatter model, then it should mean significantly faster renders while maintaining realism (that is assuming you are using adaptive sampling).

[Hadriscus]

@Metin_Seven

Does anyone know if the new curves hair engine adapts vertex colors from the source mesh?

It’s based on geonodes so it should just be a matter of transferring the attribute from the scalp underneath.

[AlexeyAdamitsky]

@TheRedWaxPolice

Principled BSDF: Lukas is investigating an upgrade to the Principled BSDF, adding more features and solving some long standing issues. A task with a plan for this will be created. There are many things to balance: usability, production vs. game engines, compatibility with other apps and file formats. The first step is to replace the multiscatter GGX with a regular GGX that uses albedo scaling for energy conservation, which should be faster and reduce noise.

It’s a high time they are taking care of this.

I’d also love to see Cycles adopting Arnold’s Standard Surface shader. Redshift has already adopted it and Octane is in the process.

[Ace_Dragon]

It would be nice if the Principled Shader had a mode that was focused on physical accuracy (as opposed to the current art-house focus more suitable for toons). The reason why is because a lot of people from other software ignore the building blocks (which give incredible results if you know how to put them together), and then conclude that Cycles is a low-quality engine incapable of producing realistic imagery.

That is one reason why I don’t use the Principled Shader myself (that and the fact that using the individual blocks does not make me dependent on the whims of the devs. regarding certain effects). Now I know that tonemapping can play a role as well, but that is being dealt with.

[obsurveyor]

@Ace_Dragon

It would be nice if the Principled Shader had a mode that was focused on physical accuracy (as opposed to the current art-house focus more suitable for toons).

I think this is the funniest description and request of the Principled Shader I’ve ever read.

[Kologe]

Motion Tracking Workshop April 2022 Report — Developer Blog

No developer meeting in the strict sense, but I suppose it belongs in this thread anyway.

Unlike other cases where proportional editing happens in 2D or 3D space, in motion tracking we need to do proportional editing in the time domain.

This (a quote from the above blogpost) makes me wonder, wouldn’t this be something we’d want for greasepencil too?

greetings, Kologe

[Kologe]

30 May 2022

Notes for weekly communication of ongoing projects and modules.

Announcements

• New Blender developer job openings
• The first biweekly geometry nodes submodule meeting will be this Wednesday: 2022-06-01 Geometry Nodes sub-module meeting (upcoming)

Modules & Projects

• 2022-05-24 Render & Cycles Meeting
• 2022-5-25 Sculpt/Texture/Paint Module Meeting

New Features and Changes

User Interface

• Use visible regions when showing candidates for operators data-path (commit ) (Campbell Barton)
• Add missing tooltips for the shader node options (commit ) (Arye Ramaty)
• Wayland
  • Support mouse buttons 4-7 (commit ) (Campbell Barton)
• Asset Browser
  • Show “Current File” icon in sidebar source field (commit ) (Julian Eisel)

Geometry Nodes

• Skip Capture Attribute node if attribute output is not needed (commit ) (Iliay Katueshenokc)

EEVEE

• Support Curves attributes rendering (commit ) (Kévin Dietrich)

Cycles

• Add half precision float support for volumes with NanoVDB (commit ) (Patrick Mours)

Grease Pencil

• Add a Ping pong effect to the Time modifier (commit ) (Aleš Jelovčan)

Python API

• Add mathutils.Color functions to convert color spaces (commit ) (Brecht Van Lommel)
• Add UI support for showing candidates for string properties (commit ) (Campbell Barton)

Weekly Reports

Summary

• Bastien Montagne
• Campbell Barton
• Chris Blackbourn
• Germano Cavalcante
• Jacques Lucke
• Jeroen Bakker
• Jon Denning
• Julian Eisel
• Kévin Dietrich
• Omar Emara
• Philipp Oeser
• Pratik Borhade
• Sergey Sharybin
• Sybren Stüvel
• Thomas Dinges
• Yiming Wu

[gorion103 (Zuorion)]

@gorion103

Huh, only 4 projects?

Blender has been accepted for GSoC 2022

@ThomasDinges

There are various reasons for that. First of all we didn’t get as many applications in the first place this year (other organizations observed something similar). And finally we settled for four projects because the remaining ones weren’t convincing, very brief (mostly copied from our ideas page, without own additions), had an unrealistic schedule or people didn’t communicate well (or at all) with module teams before hand.

[zeauro]

On the other hand, they are trying to recruit 4 senior developers at 4 for stable positions.

• A MacOS developer
• A developer for Hair and Physics
• A Rendering developer for Texture workflow, Heavy Scenes, Cycles and Material Interchange
• A developer for Animation System

[Metin_Seven]

@obsurveyor

@Ace_Dragon

It would be nice if the Principled Shader had a mode that was focused on physical accuracy (as opposed to the current art-house focus more suitable for toons).

I think this is the funniest description and request of the Principled Shader I’ve ever read.

The solution might be to have just two universal shaders: Principled for quick artistic but less physically accurate results, and a Physical shader. It would clean up the many one-trick shaders we’ve still got.

[moony]

@Metin_Seven

It would clean up the many one-trick shaders we’ve still got.

What does this mean?

[Metin_Seven]

What I meant is that the now-separate SSS shader, Diffuse shader, etc. could be integrated in one Physical shader. The input and output would then be identical to the separate shaders, so the separate shaders would not have any advantage left, allowing the amount of separate shaders to be decluttered.

[Hologram]

I’d say, put this on RCS with a copy and paste and you’ll have my vote.

[moony]

Nah, that would be a bad move IMO. Individual shaders are vital for complex node groups. Replacing say 3 glossy shader nodes with 3 principled-esq nodes would massively complicate and bloat such node groups.

Principled-esq nodes have their place, but they should not be seen as the be all and end all.

[Ace_Dragon]

Not to mention this would force users to rely on the devs. to provide certain shading features (as opposed to the current system which allows you to hack it together yourself).

To Metin, keep in mind that the building blocks are in fact the reason why Cycles is capable of pretty realistic shading as of 3.2 (because as mentioned, realism was not the goal of the Principled Shader). I am not sure if version 2 will make things better in that regard, but the building blocks are a key reason for Cycles’ competitiveness with the commercial offerings.

[SterlingRoth]

I agree that the molecular shaders are valuable and worth keeping in, but I do wanna push back against the idea that the principled bdsf is really holding back blender.

I know that we, as CG people can get really into the nitty gritty. Most of the people that need CG work done are not CG nerds like us. I have never had a client look at any of my work and reject it on the basis of the shaders not being “realistic” enough.

There are a bunch of different users with a bunch of different use cases, and for 95% of cases, the principled shader works great. For highly technical users, or very specific needs, there should continue to be the building blocks needed to make a more convoluted node tree, but please please please, don’t confuse complexity with value.

I could spend hours building up the perfect shader graph for the perfect effect that works just so under all lighting conditions, or I could spend 5 minutes plugging some values into the principled node. If the two paths don’t lead to a significant difference in my clients (untrained) eyes, then the more convoluted path is a waste of time and money.

[Ingapambi (John)]

Is there a link mentioning principled 2?