Excellent! Gotta update my vid now…lol …the updates are right on time 
2 Likes
The latest one I can see is ‘E_cycles_2.8_v20190607_lin_june_beta.tar’ - is this the new build?
Great job at speeding up Cycles!
I was wondering if you would consider working on some missing rendering features that would help with photorealism, like bokeh textures, optical vignetting, longitudinal chromatic abberration?
I remember seeing that someone actually added bokeh texture support but that never got in master.
2 Likes
Hi and no, this is the build not working with OIDN oiser.
Linux builds are on the way.
Cheers, mib
1 Like
Thanks Mib, didn’t notice that part of bliblubli’s post.
Hi Norka,
yes it’s normal 
The new builds for Linux (2.8x and 2.79x) and Mac (2.79x) are up. The linux version now has the libs shipped with. If it works well on all distros, I can delete the readme for Linux and the lib package. Crossing fingers 
The Linux builds are definetly the most time consuming ones due to the libs, but lucky enough it also has technically competent users. Thanks a lot to @mib2berlin @jensverwiebe and @mag.py for your help in troubleshooting the issue with OIDN.
Hi,
could you show a visual comparison of what you want against what is already available in the camera panel
and the compositor for vignetting and CA?
I don’t mean to speak for chafouin but I think they mean a real physical implementation of those effects in the raytracing. The differences would be subtle but very significant as I believe our eye can tell the difference, ultimately. It would be gorgeous if it could be done!
It could be done, but actually if you want vignetting physically simulated, you can already have it by modeling a real lens parented to your camera.
For Bokeh, I didn’t look in the implementation in the camera model of Cycles, but I think it’s already pretty much what you want?
For CA, physically simulating this kind of dispersion through several glass elements would be very costly on the compute side I think. Providing a database to replicate real lenses would also be pretty time consuming. Maybe there are some good implementations with a sweat spot between physical correctness and compute time out there, but I don’t know any. If you have a good paper or source that implement such things in an optimized manner, I could have a look.
1 Like
It’s working on Manjaro. Thanks.
1 Like
Its not working yet on Mint19, perhaps you missed my point:
From what i see you forgot to: patchelf --set-rpath ‘$ORIGIN/lib’ blender
so this results in a preferred lookup in blender dir/lib.
Example:
ldd blender
linux-vdso.so.1 (0x00007ffcf73e7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f80d9260000)
libOpenImageDenoise.so.0 => /media/Workdata3/Development/E-Cycles/E_cycles_2.8_v20190612_lin/./lib/libOpenImageDenoise.so.0 (0x00007f80d6b54000)
...
libtbb.so.2 => /media/Workdata3/Development/E-Cycles/E_cycles_2.8_v20190612_lin/./lib/libtbb.so.2 (0x00007f80d4d5e000)
libtbbmalloc.so.2 => /media/Workdata3/Development/E-Cycles/E_cycles_2.8_v20190612_lin/./lib/libtbbmalloc.so.2 (0x00007f80d4b07000)
...
and that was enough to make the right OIDN found ( + tbb + tbbmalloc in this case ).
If you like you can do this while compiling instead, makes patchelf obsolete for blender then.
Add to cmake :
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH "$ORIGIN/lib")
OIDN comes precompiled, so the postoperation with elf eding is needed.
To assure also libOpenImageDenoise finds an delivered ( correct version ) of tbb and tbbmalloc also do from blender/lib dir : patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0
which results in:
ldd libOpen*
libOpenImageDenoise.so:
linux-vdso.so.1 (0x00007fff77589000)
libtbb.so.2 => /media/Workdata3/Development/E-Cycles/E_cycles_2.8_v20190612_lin/lib/./libtbb.so.2 (0x00007ff36a71e000)
libtbbmalloc.so.2 => /media/Workdata3/Development/E-Cycles/E_cycles_2.8_v20190612_lin/lib/./libtbbmalloc.so.2 (0x00007ff36a4c7000)
See the concept ? It may not be mandatory on distros which match the requirements, but assure on non-matching ones blender and libs get the right versioned libs (api ).
Check with: patchelf --print-rpath and/or ldd to assure succes.
BTW: Ppl can alsways do this afterwards if anything went wrong.
Cheers Jens
Hi Jens, actually I did exactly that before packing the folder 
I’ll make a script to ensure it is done correctly.
It is working now on Opensuse Tumbleweed 64
Cheers, mib
1 Like
The output here was:
$ patchelf --print-rpath blender
‘/lib’
$ cd lib
$ patchelf --print-rpath libOpen*
‘/’
but should have been:
$ patchelf --print-rpath blender
$ORIGIN/lib
$ cd lib
$ patchelf --print-rpath libOpen*
$ORIGIN
This should make the misunderstanding clear.
( BTW: “ORIGIN” is a reserved linkage keyword for the location the actual binary is running from )
Jens
1 Like
I definitely don’t have any papers to link - just talking out my butt without knowing anything about implementation! Thanks for your response - great thoughts on things to play with in the existing paradigm.
1 Like
Hi Jens,
I uploaded a new version which should be good. Can you confirm? I had 10 things to do in parallel today so concentration could have been more optimal.
The actual hosted 2.8 version is perfect mate 
Going to check 2.7 version now …
… yo man, 2.7 version is fine as well now.
Jens
2 Likes
Yo Man, vielen Dank für die Hilfe 
Mathieu
1 Like
hey guys - don’t disturb bliblibli - he’s working hard on July update. SHHHHHhhhhhhh
1 Like