Sergey and Brecht continue to work on light linking. There is now an improved UI, support for excluding objects. Optimizations for the light tree are being worked on but need more memory optimization before landing. There is basic shadow linking support, however it currently disable multiple importance sampling. Making it compatible with multiple importance sampling will require some significant kernel changes, tracing an dedicated shadow ray instead of reusing the indirect light ray.
Weizhen worked on adding instancing support for the light tree. An initial implementation is working but needs to be cleaned up.
Lukas will resume work on the Principled BSDF v2, still aiming for Blender 3.6. That way we have one release with both v1 and v2, and then we can drop v1 in 4.0. Some changes may land in Bcon2.
Brian reports that AMD has a fix for the internal compiler error, and a new HIP compiler is planned to be sent for testing in the next few days.
AMD HIP-RT code does not require immediate further changes, but Brecht needs to find time to build and test it before it can be accepted. Hopefully we can first enable HIP again assuming the compiler fix works, and then enable HIP-RT soon after.
The upgrade to Embree 4 with hardware ray-tracing is progressing. The patch for the Embree 4 CPU changes was accepted but needs a review from the Windows maintainer still. The hardware ray-tracing patch still needs to be fully reviewed. This will require an updated to the oneAPI runtime precompiled libs to fix an issue on Linux, which can be done together with new Embree 4 libs.
Christophe asked about the spectral rendering support. We still want to incrementally merge changes as soon as the developers of this branch submit them. However the changes to change shader sockets from RGB to Spectrum was not considered something we want, as it makes MaterialX and OSL compatibility difficult. Instead we suggest to follow other production renderers, that also use RGB sockets and can handle full spectra as features of closures / shader nodes.
The AgX view transform was submitted for review, which improves handling of bright HDR colors, making them go to white instead of saturated colors, an issue that both Filmic and ACES suffer from. We want to include this in 3.6, but this needs to be fully reviewed and may need code changes to ensure it has good backwards compatibility.
The Cycles standalone repository will be updated to 3.5 soon. This required some significant changes to handle the new VFX platform 2023 libraries and C++ ABI. Compatibility with DCCs still on VFX platform 2022 is likely not going to work, remains to be seen.
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.
Could be interesting to have a setting in preferences to be able to change the OCIO config folder, even if it requires a restart of Blender, this way we could easily change between Filmic, agX or even use ACES easily
I think I’m beating a dead horse but just in case it might help someone:
You can already either set up an “OCIO” environment variable containing the path to the ocio.config you want to use (system or user-wide).
Or you could also (in Windows) create a .BAT-file containing two lines:
set OCIO=\path\to\ocio.config
\path\to\blender.exe
In Linux you could create a shortcut a la:
OCIO=/path/to/ocio.config /path/to/blender
…and Blender starts with your OCIO config. The advantage is that you can create several of these if you switch between configs a lot.
P.S.: I see a lot of people manually copying their favourite OCIO config into the blender/3.x/datafiles/colormanagement-folder which is not only cumbersome but also error prone. Please use an OCIO environment variable instead. By the way: this also works with any application supporting OCIO like Houdini, Nuke, Fusion, …
We use that, the thing is to make things easy for the user, en environment variable is not something everyone understands, also if you want to shift between one OCIO and other because you are working in two different projects this makes it complicated unless you do like we did, an script to run it specifically.
In the end the OCIO config is something that at least we should be able to define in settings, not with an env variable.
In the end, and this is just a personal opinion, the OCIO config setting is something that should be saved in the blend file, not in blender preferences, that makes it flexible, but imI think this is is a conversation for another thread.
The thing is that if we are going to have AgX and Filmic (I expect Filmic will be around for some time, and not force the change to AgX) we also need an easy way to deal with different OCIO configs, and not the environment variable, which is complex
Here’s my thoughts about light linking:
I’m thinking whether putting it in the Object properties tab is right.
Wouldn’t it be better if the light linking settings were attached to the object data, and not per object? And more than one similar light could have linked light linking settings?
Also, I think the user should be able to input more than one collection into the list. The user then could either expand the collection to see every object within it and adjust their settings individually, or adjust the settings of each collection as a whole. Something like that. But then this kind of becomes like a mini outliner in the properties editor, which is a bit weird…
Or Maybe, this is a way better approach?:
Instead of making light linking a setting for a light, it could be a setting for a mesh object or a collection instead. It’s kind of like an approach from the other end.
The Light linking settings would appear in the Objects tab of a mesh, and or the Collection tab.
The user would select a mesh object or a collection, then they would add lights and or light collections to the light linking list, and choose whether or not that object or collection is affected by that light or light collection. There could also be an “inverse” checkbox so that the particular object or collection would ONLY be affected by the light or light collection in the list.
Note: Meshes can be lights too. This would allow the user to make a mesh light not affect another mesh object.
Sidenote: I think light groups should also be collection based. The way they’re implemented is inconsistent. Perhaps a change for 4.0?..
If I understand correctly, if the light linking information is in the object data, then all the instances of that object will share the same light linking information, which is not desired.
I would much prefer more of an outliner UI than the current one. There’s all kinds of objects like empties and other lights in these collections that I have to parse through to get to mesh object I want to change. Having a filter for certain types of objects like the one in the outliner would make this a lot less painful.
I also really don’t like having to click on a drop-down menu for every object who’s settings I want to change. I’d much rather have an array of tickboxes that controls if some object is included, excluded, or auto from a light. With tickboxes, I can click and drag the settings for multiple objects at once instead of going through a bunch of drop-down menus.
It would also be nice if there was a setting to turn off a light’s indirect bounce from a light linking panel. Currently, the light just bleeds onto excluded objects so I’m forced to jump into the light node editor to disable it there.
Honestly, I think the natural fit for light linking managing would be the spreadsheet, considering the amount of information it can convey at a glance. But I guess it would be a long term thing, between the design and (I guess) changes to the spreadsheet code(it would need to be transformed into an actual editor, not just a viewer)
I too like light linking in the object properties, instancing lights would be difficult without it.
But I’m not sure about collection inputs. There’s so much things already in Blender that require collections, like Geonodes, Freestyle. It seems like we need collection for everything. But what if I have objects A,B,C and want Freestyle on A and B, I create a collection and put them there, but I want light linking on A and C, I have to make second one and have A in both.
Doing that for many light sources separately just bloats the outliner with same objects in many collections.
Wouldn’t it just make more sense if instead of collections it just used objects? Like a list, similar to Vertex Groups, where you input which objects you want linked, and then you could also add entire collection as an object if you like
A single object can be in multiple collections.
You can organise your collections pretty well inside the outliner, if you place collections that you want out of the way, to be in a single collection, which is just not expanded… But if that’s not sufficient, a collection can be unlinked from the scene and linked to another… There’s a lot of power there…
I tested the latest build of light linking and I noticed that it disables the emission of a material if it’s used as a light to be linked to something else.
In the attached image I selected this green mesh light, added a cube as a light link and it automatically disabled the light from the mesh. Is this a bug or intentional?
I suspect it might have something to do with how the object isn’t “light linked to the camera”. Although I haven’t tested this branch, so I don’t know if linking to the camera will fix this issue.
