Someone has already made some lens simulations with the ray portal BSDF, and the results seem quite good!
Yes, I know what Heinzelnisse has been doingâŚ
Iâve been doing similar experiments with the RayPortal myself (thought Iâve been using 2.5D variations of the ray transfer matrix, and heâs using full refraction math).
But even so, as I mentioned above, the problem is that using the RayPortal doesnât converge fast enough to a noise free solution (too many samples where arenât needed, and too little sampling where it does)⌠Having Cycles to be able to converge faster is needed, and Lukasâ PR might improve that a lot.
How would things like Path Guiding and Light Trees work when portals are involved, because last I checked it does not appear to be something that is commonly utilized in patch tracing?
If these things have full compatibility with portals already, then that would be a surprise.
The RayPortal doesnât do any fancy stuff⌠it is actually very simple and it just moves the ray to another location and direction.
I donât know how exactly Path Guiding works, but I think it deals with the RayPortal the same way as any other closure. (after all, the Transparent bsdf is the only closure that doesnât change the ray vectors.)
But in relation to custom lenses, the problem isnât really the PathGuiding⌠Itâs just that rays from the film sensor (camera), have too much variation, in a similar manner as DOF.
OpenPGL on GPU is advancing. Sebastian is working on making it so the render info is gathered from the render kernel
At the Blender Conference there was a demo of OpenPGL working on GPU with pre-exiting render info.
This is good to see.
Attendees
- Lukas Stockner (Blender)
- Nikita Sirgienko (Intel)
- Patrick Mours (NVIDIA)
- Sahar A. Kashi (AMD)
- Sebastian Herholz (Intel)
- Sergey Sharybin (Blender)
- Thomas Dinges (Blender)
- Weizhen Huang (Blender)
Notes
- For 4.3
- CPU / GPU difference
- The fix has been commited to
main
. Avaiting backport. - The report can be closed?
- The fix has been commited to
- Handling SDK/ROCm 6+ lack of backward compatibility with pre ROCm 6 #130153
- Sergey will check on avoiding cache variable and use
find_package(HIP)
inextern/hipew
- Requires re-compilation of HIP-RT on Linux to prefer ROCm 6.
- Sergey will check on avoiding cache variable and use
- CPU / GPU difference
- Other
- Lukas keeps working on the OSL camera. Getting close to the state where public testing will be needed. Feedback thread coming up!
- The meeting went into discussion in the mix of signed and unsigned for arithmetic. The solution seem to be:
- Use signed arithmetic
- Add assert() in cases where something is not expected to be negative
- Convert macros to inline functions if that helps compiler
- OpenPGL on GPU is advancing. Sebastian is working on making it so the render info is gathered from the render kernel
- At the Blender Conference there was a demo of OpenPGL working on GPU with pre-exiting render info.
- The module will look into creating a task for the Quality project, to make it more visible and clear
- Weizhen works on octrees
- Switched to per-volume octree to make updates more instant
- Need to solve overlapping octree case
- perlin noise: hash and fmod are slow
NOTE: In order to solve scheduling conflict with some of the active contributors the meeting is moved 2 hours earlier, at 15:00 CET.
Volume rendering update
Already looking promising
2025-01-07 Render & Cycles Meeting
Attendees
- Brecht Van Lommel (Blender)
- Sergey Sharybin (Blender)
- Nikita Sirgienko (Intel)
- Sahar A. Kashi (AMD)
- Xavier Hallade
Notes
- For Blender 4.4
- HIP update to 6.2 is on-track. Question about what version to target for for gfx12. There is a bit of version difference between Linux/Windows
- Linux 6.3
- Windows 6.2
- Will sync-up with Sahar in the task tracking the update: #131976 - Cycles: Update ROCm/HIP to 6.2.4 for Blender 4.4 - blender - Blender Projects
- Embree update
- New Embree fixes threading-related bug leading to crash
- Wait for the update from Nikita
- OIDN update
- Need to update the libraries tracking: #128577 - Library changes for Blender 4.4 - blender - Blender Projects
- DPC++ will need to be updated. Details coming
- Pre-compiled kernel compression is coming!
- HIP-RT will be updated as well
- Point cloud fixes
- Bytecodes do not need to be compiled
- HIP update to 6.2 is on-track. Question about what version to target for for gfx12. There is a bit of version difference between Linux/Windows
- Other
- Brecht cleanup Cycles for clangd: Using clangd
- Make it somehow more clear for people who does benchmarks that LTS is not the best to depict performance on the new released hardware.
- Add a warning in the benchmark launcher?
- Add a warning in the Blender LTS itself when a device from the future is detected?
Anything holding up the OpenPGL upgrade, otherwise it is looking like a very light release for Cycles coming up with the vast majority of changes being invisible to the user?
for people stile using 2.93 LTS OR old Cycles
Blender is flying on this poor little GFX8 (Polaris 20, 8 GB).
Great to known that even older Blender (most likely LTS 2.93) is working with
rusticl
on old GCN4 aka GFX8 hardware.
ROCm is by the way not an option here because it only supports RDNA based GPUs (and with some tweaks maybe certain GCN5 / GFX9 models.)
Havenât been following Cycles lately. What are the big projects being developed ?
Any news on Open PGL GPU, ReSTIR, MipMaps, Spectral, ⌠?
Here is an updated on the cycles development:
Library updates, developer tooling and communications for benchmarks, is that all ? Arenât Lukas and Weizhen working on Cycles ?
Feels like the last large batch of features was 4.0 more than a year ago, with AgX, Path Guiding, Principled BSDF and Light Linking.
Donât want to sound disgruntled, just curious about what happened this year.
If you are truly curious, you are in luck, you can see every single line of code touched by any of your favorite developers right here:
Also, if you donât want to sound disgruntled, avoid using the phrase âis that all?â and shrugging emojis.
Ah my bad, got it !
OSL Cameras, Volume octree optimizations, Open PGL on GPU.
Hope we get news soon about mipmaps, ReSTIR and Spectral !
Whatâs that now? What happened to OpenPGL and GPUs? Is it working on GPUs now?
Wishful thinking.
We might hear about it sooner than later ! Doesnât seem that wishful.
Might even come with a cherry on the top
Sounds like wishful thinking. I bet itâs still going to be a few years.