2022-09-20 Render & Cycles Meeting


  • Brecht Van Lommel (Blender)
  • Thomas Dinges (Blender)
  • Christophe Hery (Meta)
  • Brian Savery (AMD)
  • Nikita Sirgienko (Intel)
  • Stefan Werner (Intel)
  • Xavier Hallade (Intel)
  • Patrick Mours (NVIDIA)


  • Path Guiding:
    • Brecht works on a few remaining changes to make it ready for master, hopes to merge this week.
    • There will be a new OpenPGL release with optimizations and fixes. The library can be updated to the new version independent of the merge.
    • AVX2 is broken in the current OpenPGL version, Brecht will temporarily disable it.
  • OSL GPU:
    • Various code refactors for this were merged to master.
    • Patrick is working on upgrading to the latest OSL version, currently encountering some render errors.
    • Patrick will create developer.blender.org task with to do items.
    • We want to avoid dependency of OSL build on CUDA toolkit and OptiX. OptiX is easy to remove, CUDA may be possible by using clang though this has some issues currently. For OSL the plan seems to be for this to not be a requirement at all, but timeline is unknown.
    • One missing feature is image texture loading through file paths, may be possible to make it work by querying OSL shader and loading in advance?
  • Intel oneAPI:
    • Patches for oneAPI linking and kernel profiling needed review, hopefully done this week.
    • Stefan looks into adding support for using host memory fallback.
    • There is a performance regression related to matrix inverse changes, will be looked into.
    • Hardware ray-tracing aimed for Blender 3.5.

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.


How’s the Principled BSDF v2 going? It’s been so quiet for some time since the last update on this branch.


Is there any information that can be shared as to why AMD Hardware ray-tracing changed from being aimed at 3.4 or earlier about 4 months ago to the current aimed for Blender 3.5? Just curious what difficulties are being encountered.


All the early estimates, the new eevee from 3.1 to 3.5 delayed

Nice. Will the new OpenPGL version allow GPU-powered Path Guiding?

@MetinSeven GPU support will still take some time.
We first want to figure out how to do path guiding robustly in a production context.
When this is done we gonna focus on porting our learned lessons to the GPU.


If I had to guess, I’d say it’s related to the upcoming RDNA3 launch. They probably don’t want to launch HIP-RT until it supports RDNA3, as raytracing performance on RDNA2 is kinda lackluster. So marketing, really.


I feel like my wallet has been emptied again :smiling_face_with_tear:

All development planning is rough estimates. Something else might come up that needs attention, some implementation may take a bit more work that planned, etc.

We’re being open with Blender development process, please don’t use that as an opportunity to invent a narrative about development being postponed due to marketing, that’s just not true. Not saying there is any ill intent, just remember this forum is for collaborating with developers.


I have been doing some tests with the latest branch build on Blenderartists and noticed that path guiding can be a bit hit and miss. Sometimes the guiding finds the difficult paths and sometimes not.

I guess its doing some sort of random sampling and sometimes simply misses. I have posted some images to illustrate:

A question has been asked about how this might affect animation - does the guiding algorithm remember the paths between frames - or does this have the potential to cause flicker between frames (i.e. is path guiding temporally stable)?

1 Like

Note that path guiding is not designed for caustics, it can help with them but that’s more of a side effect. If you use it to render effects like that, where some very bright paths are rarely detected, the result will not be temporally stable in general.


Ok thanks - that clarifies things

1 Like

A quick question - what platforms will have path guiding support initially?

only cpu at first, gpu support will come later

I should specify that I was asking about OS platforms.

Path Guiding in Cycles using OpenPGL is officially supported on the platforms Blender is officially distributed on. That’s Windows (x86), Linux (x86), MacOS (ARM and x86).


is it possible to implement Hip-RT on AMDGPU open source? because it would be much easier to work with AMD cards on Linux with free drivers, RT is for game so I believe it is possible and no need to install driver, specially for other distros (I use Manjaro), or if not implemening EEVEE+RT shadows also I think would be a good combination, what about other options for render like Vulkan?


Working on hiprt for cycles, 3.5 out