2024-06-25 Render & Cycles Meeting

Meetings
1

Attendees

  • Brecht Van Lommel (Blender)
  • Sergey Sharybin (Blender)
  • Weizhen Huang (Blender)
  • Lukas Stockner (Blender)
  • Nikita Sirgienko (Intel)
  • Patrick Mours (NVIDIA)

Notes

For 4.2

  • Decided to accept the performance impact on AMD/Intel Metal
    • The slowdown only happens on specific hardware, which developers have no access to.
  • High prio reports:
    • Cycles HIP-RT Memory leak #120702
      • Seems to be bug in the library
      • Fixed in the open source version, which 4.3 is switching to
      • For 4.2 wait for the possible NIP-RT update
    • Blender crashing when using metal renderer #122022
      • Michael Jones was looking into it
    • OpenImageDenoise CUTLASS error after rendering image #122584
      • All the crucial parts are fixed for 4.2
    • Illegal address error with OptiX OSL with specific materials #122779
      • Possibly a driver bug, Patrick is looking into it
      • Possibility is to accept it for 4.2 initial release, and either look into work-around later, or have a fix done from the driver side.
  • Release notes seems to be good

For 4.3

  • White point patch
    • All the current feedback has been addressed, needs the final review
    • Known limitation: no feedback when picking something that is not close to blackbody radiation
  • Compression of pre-compiled libraries has landed #123557
  • Diffuse roughness control for principled BSDF
    • Need review from the Cycles side. Weizhen and Sergey will take care of that
    • EEVEE side is done
  • Weizhen is looking into bug reports, solving long-standing issues
  • Brecht is updating Cycles standalone
    • The script cycles_commits_sync.py is in the blender.git repository
    • Takes a bit longer than usually, because of the Git-LFS changes
  • Brecht cleaned up the project workboard, so there is now a column for the near-term next tasks to tackle
  • Alaska is working on patch to remove Intel/AMD Metal codepaths. Sergey reviews, hopefully land soon
  • Volume phase functions #123532
    • NVidia paper looks very interesting
    • Lukas would love to have a review
    • Some preliminary feedback:
      • Add links to papers
      • Better explanation of what the new phase functions are on artistic level
      • Are the parameters good and friendly for artists?
      • How do you mix different lobes?
      • Replace current one with the new one?

Future:

  • Split principled BSDF node
    • Helps EEVEE parameters (the GLSL parameters limit)
    • Helps OSL to discard unused closures
    • Probably better be done on the render engine side (as opposite to the Blender side) since layering might be done differently by different engines
  • How to handle volumes
    • Best acceleration structure
    • Combine them or sample separately
    • Look into what the state of the art is
    • The meeting mainly raised this topic, needs further investigation
  • Multi-part EXR files #123727
    • Helps speeding up load of EXR in external software
    • Eventually Blender will also only load requires passes, so will help there as well
    • Implement as an option, or even by default
  • Nikita raised a discussion of solving technical debt
    • Would be good to tackle it shorter term, and not for Blender 8.0
    • Testing frameworks are available already, but some aspects of Blender/Cycles might be hard to unit test
    • Need to look into it, and make code easy to unit test
    • Sergey is very interested in this, but has limited time. Nikita might have time to look into it for the denoise device selection
    • In the longer term we should strive towards accepting new features with tests included
  • Another technical debt topic was splitting up CMakeLists.txt. Could help some on-going development
  • There is old-standing patch to rework CUDA kernel build to use separable compilation #119746
    • Is still something to look into, but needs development time and priority
  • Doing kernel compression for AoT Intel kernels is being investigated

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.

15 Likes
2

Is finishing existing tasks like the ones that are mentioned below (and many more) on the agenda?
A lot of them are near-done or have been half-done with no progress or attention for years.
Will there be a project similar to the GP3 or Brush Assets to finish these tasks? (Because, in my opinion, the ongoing projects are a big success.)

  • Cycles Light Linking #104972
  • Cycles: path guiding #92571
  • Cycles shadow catcher improvements #71253
  • Cycles: improve shadow terminator handling #68920
  • Cycles: GPU Performance #87836
  • Cycles light spread importance sampling #87053
  • Cycles: adaptive sampling improvements #74581
  • Cycles: Embree improvements #73778
  • Cycles: Many Lights Sampling #77889
  • Cycles: volume sampling improvements #92570
  • Cycles: CPU batched execution for performance #92572
  • Cycles OSL with OptiX #101222
13 Likes
3

Yes. It is matter of prioritization within a limited time availability.

6 Likes
4

Ok, great to hear!
Are you considering doing something similar to the current Projects agenda (or “task force”), like GP3 or Brush Assets, but with the remaining Cycles tasks like the ones I just mentioned?

5

It is a bit tricky of a question. A lot of things for GP3 is a task-force because a huge amount of work is needed to bring back the feature parity. Also, a lot of those do not require deep knowledge of how path tracer work. Point is: task force would be much less scalable for things in Cycles.

The tasks we are creating for Cycles are more from the perspective of “how do see the ideal design for the new system”. For some of those tasks finishing the last bits of TODOs could mean organizing an actual project with few people working on it, as it comes quite outside of the scope of just Cycles. Those are handled more like an iterative process of looking into overall state of Cycles, what are the priorities, what is the development power available,.

Some other tasks it is a bit more straightforward, as it is “just” a TODO from the Cycles side. Those we are trying to schedule across Cycles developers for the next releases.

7 Likes
6

Ok, great! Thanks for the response.
It really clarified things for me.
And sadly, the more complex a thing is, the fewer people who know how to deal with it.

7

The one thing I think should be prioritized to “get it done with” is Adaptive Subdivision, poor thing was in experimental for like 7 years and the Feature Set dropdown only exists because of it.
Though I imagine it was on the backburner for so long that design goals have drastically changed and the whole feature will have to be re-evaluated.

5 Likes
8

You’re pretty much nailed it :slight_smile:
It is indeed one of the topics which we’d like to be wrapped up.

7 Likes
9

Just out of curiosity, how do you prioritize what tasks to tackle next?
What are the characteristics of a task that needs to be tackled in the next release, quarter, six months, or next year?

10

Oh, that’s quite a question! Not sure what an easy answer for that would be. Team availability is a big contributing factor for that.

Typically we’d try schedule a number of things for the next release. And for that if there is an on-going task we’d try to finalize it. For things that are limited to Cycles core this is a bit easier, and we can just pick up some things within the module. If it goes outside of the Cycles, then we’d need to be seeing the team availability.

Some community and studio feedback also have a role at the planning. For example, it is possible that something with a bigger time investment requirement will be prioritized over something else because it’ll have a bigger impact on Blender as a whole.

There is also times where the Blender Studio will bring some requirements for an upcoming project. Those we try to incorporate into the timeline in a way that everyone benefits.

The developer motivation is also a factor when it comes to picking up a task.

So yeah… Is quite some factors to weight in when making decision.

9 Likes
11

This post was flagged by the community and is temporarily hidden.