Nice to have…at least as option… I prefer to be able to render an image in a longer time than no render at all or have to do more workload to reduce texture resolution or buy more RAM or a new videocard with more ram.
Obviously, if they can find a way to reduce the performance loss…well…in that way more than welcome. I remember that, speaking about Vray, the features that, in the past, were used to render big images or big scene with a limited RAM were at a performance cost…so I think that if this was working for Vray…I think it will work for Cycles because as I wrote before…it’s better to render a scene in more time than don’t render at all.
Blender decided to add support for the OpenPBR uber-material model in a future release. The OpenPBR material shading node will be an alternative to the PrincipledBSDF material. Other than the Blender specific PrincipledBSDF, OpenPBR is a standardized material model that is fully supported by multiple renderers and DCC software packages.
Well at least in their tests the performance loss seems quite acceptable !
It’s logical that finding the appropriate texture size comes with a cost… but as you said maybe it’s better to way two second more rather than having no renders at all
This will potentially benefit significantly ArchViz workflows, among other fields.
Avoiding the good old Symplify’s Texture Limit all-or-nothing approach for texture resolution could help a lot, beyond the ability to just render a scene that hardly would fit in any rendering device.
We use dozens or hundreds of assets per scene. And they don’t easily fit in the VRAM of most GPUs. Having all assets with middle to high resolution but automatically scale them down as needed per asset and contribution to its shot instead of limit the top amount of resolution size for the whole scene solves major headaches and reduces significantly the amount of workarounds needed to fit scenes in VRAM.
We can always go CPU, bigger GPU VRAM, and all sorts of tricks, but this can potentially be a massive help.
Its usefulness is not limited to rendering. I can confidently make my own assets with high resolution texturing and details and count on them to not kill my shots. I can be sure the same asset will work on close-ups but won’t kill my scene if its pixel real estate on the final render is small but still has massive textures.
It’s similar to what adaptive subdivision offers for our meshes but for textures, if you will.
Texture caching and mip-mapping is truly welcome. Big thanks to the developers!
Yeah you’re definitely right here ! I think this is beneficial for every heavy projects lie Arch-Viz, VFX or feature-film quality animation. It’s indeed a massive step in allowing blender to handle more complex projects. and yes this allows to be a bit more sloppy with assets and you can do massive textures and let cycles manage their size. For that to be completely efficient I guess eevee needs to catch up so this principle follows in every parts of blender …
Also I’m wondering what appends if say you’re on viewport preview and zooming toward an asset, is blender going to slowdown each time it loads a different mip level, or it will keep the initial one…
So yeah I guess it’s a great new thing we can rely on but maybe not the time to throw old school techniques to save memory out of the window either.
Sebastian spent time on organizing the project: setting up tasks etc
Have it working for OSL: coating, phase, metalling, emissive, transmission components. Mising subsurface and thin film.
Next step is to port it to SVM and EEVEE. This is what Sebastian is currently working on.
Work to compare Cycles with other renderers is in the works. Working with OpenPBR WG to introduce testing.
Weizhen is working on anisotropy support for SSS: negative anisotropy was not supported. This in the context of thin sheet (thin surface, wall) support.
Cycles standalone repository has been updated. Both 5.1 and main Blender branches.
We’ll try to keep it up to date more regularly.
Other
Brecht is working on SVM refactor
Goal is to avoid packing to uint4
Will be using proper data structures
Sahar looked into remaining HIP-RT issues
Some of them were actually resolved
BVH memory usage still needs work
The Rock integration: PR for integration is coming up
The problem is that the runtime currently need to be linked against non-opensource library on Windows, which is a problem
No conclusion could be done during the meeting. Sahar will bring it up internally
Patrick: we’ve run out of sockets in the Integrator class
Such unilateral motor control is impossible to achieve without a good rig or a background in wrestling. But ultimately, unabashedly, does not answer my question
This mention of “The Rock” is needlessly ambiguous. It leaves everybody wondering what the involvement of a wrestling star turned movie icon is exactly with the free software movement. Is Dwayne Johnson a platinum sponsor ? does he have vested interest in spectral rendering ?
“The Rock” is a new initiative by AMD to streamline the build process for ROCm. It is designed as a unified CMake super-project that provides a cleaner, more efficient way to build ROCm components and PyTorch from source.
Was it an inside job sabotage? 
