The other requests were more about merging some patches. That’s were the course is best suited normally. But if their is a common ground agreed on by a good chunck of the E-Cycles user base, merging patches could be doable, as long as I only have one main branch to maintain.
Those are not ideas, those are ready products. I could just upload them on the BlenderMarket and Gumroad as is for a third of the price. People joining in the current state would then get the improvements for free and when it reaches the quality I want, it gets the full price.
2 Likes
Well I think you have certainly more than earned your credibility in developing products to their potential and supporting them. As such the idea of buying early at a discount seems reasonable especially if you make that clear in the description. I can understand if you would want to develop them more rather than deal with people prematurely peppering you with complaints, though. I am very curious… can you tell us what part of workflow they are related to?
My latest tests with E-Cycles + FLIP Fluids, fast!
3 Likes
One of them is related to texturing, it’s mainly for architecture. It makes auto UVs at render time so that you don’t need unwrapping anymore.
5 Likes
Hardcoded triplanar mapping? Would be useful!
1 Like
Cool comparison as usual. I’m even more happy you did it, because it shows that even with fast preset, it renders of course faster, but also with better quality by doing the full path bounces, giving really realistic water.
If the black blotches are ok and speed is important, you can set the light path bounces to the same value in both scenes and get even faster render with E-cycles
3 Likes
Awesome! and thanks for the tip. E-Cycles is super exciting to use with FLIP Fluids cause usually in the past you could have a superb FLIP Fluids bake, then when it came to rendering Cycles would choke on massive refraction and reflections leading to long render times which just kills the creative enthusiasm. E-Cycles optimization on the other hand just totally shines in regards to rendering complex materials and geometry such as what FLIP Fluids generates making it a joy to render with. I’ve become a fan of the Fast preset, Medium is my go-to preset, but once I get a good render with it I’m like “I bet I can tweak the mess out of this in Fast and get a better time”…lol
2 Likes
Also just watched your’e latest E-Cycles tutorial, verrrry helpful. Especially the visual breakdown of the Noise/Scrambling. 
1 Like
I can’t get the AI denoising to work on Manjaro Linux. I’ve tried installing OIDN both via the package manager and manually as described in readme_Linux_new.txt. The Denoise node just passes the image straight through. No errors in the console.
Did you use the _tmp version ? It doesn’t contain the OIDN code as it crashes on some Linux distro. This version is only meant for one person hit by the bug until I release a proper bugfix. The 20190607 version should work. If not, please provide a file and I’ll check on Manjaro.
No it’s from E_cycles_2.8_v20190607_lin_june_beta.tar.bz2. I redownloaded just to make sure.
broken_denoising.blend (720.1 KB)
Forgot to mention that it’s the Gnome variant of Manjaro that I’m using.
Edit:
If I disable and re-enable the denoiser addon I get this in the console:
TypeError: PointerProperty(...) expected an RNA type, failed with: RuntimeError: , missing bl_rna attribute from 'RNAMetaPropGroup' instance (may not be registered)
Writing: /tmp/blender.crash.txt
zsh: segmentation fault (core dumped) blender
139
/tmp/blender.crash.txt contains this:
# Blender 2.80 (sub 74), Commit date: 1970-01-01 00:00, Hash unknown
bpy.data.window_managers["WinMan"].addon_search = "den" # Property
# backtrace
blender(BLI_system_backtrace+0x30) [0x1341fc0]
blender() [0x111e871]
/usr/lib/libc.so.6(+0x378b0) [0x7fb960f638b0]
[0x7fb93b80be90]
The first error could look like an API breakage, but the BF said the API is stable now. I’ll have a look asap. Strange it works on Windows still, maybe it’s just a bug on Linux. The user I made the _fix version for had OIDN working for 2 weeks and after some updates, it broke. Maybe this update also reached Manjaro, it would be interesting to know what it was? Was TBB (libtbb it’s called maybe) updated recently on your Manjaro?
Looks like it was last updated 2019-05-26. I’ve only been using E-Cycles on Linux for a couple days so I’m not sure if it worked previously. I could maybe try downgrading tbb.
Just for info, on Opensuse Tumbleweed it is May 23, 2019: TBB 2019 U6 the latest available and it does not work with E_cycles_2.8_v20190607_lin_june_beta / OIDN 0.9.
TBB update was So 02 Jun 2019 04:53:59 CEST.
IIRC it was working before but I am not sure.
It work with E_cycles_2.8_v20190527_lin, hm.
I get no significant error messages.
Cheers, mib
1 Like
Ok I downloaded the previous build of E-Cycles (E_cycles_2.8_v20190516_lin.tar) and OIDN is working there.
According to ldd, the June build doesn’t link to OIDN & TBB:
linux-vdso.so.1 (0x00007fffe5ae1000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f03b1639000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f03b15a6000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f03b1467000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f03b1454000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f03b124e000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f03b1048000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f03b1039000)
libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f03b1034000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f03b102f000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f03b0e6a000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f03b16b1000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f03b0d24000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f03b0d0a000)
libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f03b0cd5000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f03b0cc0000)
libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f03b0c04000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f03b0bda000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f03b0bd5000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f03b0bcb000)
whereas the previous build does:
linux-vdso.so.1 (0x00007ffc0cc97000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fab8544e000)
libOpenImageDenoise.so.0 => /usr/lib/libOpenImageDenoise.so.0 (0x00007fab830c7000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fab83034000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fab82ef5000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007fab82ee2000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007fab82cdc000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fab82ad4000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fab82ac7000)
libutil.so.1 => /usr/lib/libutil.so.1 (0x00007fab82ac2000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fab82abd000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fab828f8000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fab854c6000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fab827b2000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fab82796000)
libtbb.so.2 => /usr/lib/libtbb.so.2 (0x00007fab82754000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fab825c4000)
libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007fab82591000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fab8257c000)
libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007fab824c0000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fab82494000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fab8248a000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fab82485000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fab8247d000)
Maybe you accidentally built the June build with the _fix config?
1 Like
Also on Linux, i would prefer not to fiddle with “exotic” libs in /usr etc. but rather deliver the matched ones inside the blender dir and set rpathes accordingly. Just my 2 cents to avoid conflicts.
You can do this whrereas compiling but also afterwards with for example patchelf.
( patchelf --set-rpath ‘$ORIGIN/lib’ blender to have precedence to libs in a newly created lib dir, don’t forget to eventually also change it for libOpenImageDenoise itself )
Jens
1 Like
Indeed, it looks like the CMakeCache was left with WITH_OIDN = OFF after I compiled the fix version. Thanks for the report, I’ll recompile another version with OIDN asap. I had statically linked builds for a time working, but for some reason, they also started to crash at some point on newer Ubuntus because of some issues with TBB.
@jensverwiebe I’ll try patching the elf as you said.
In the mean time, the v20190516 version works properly on all distros.
1 Like
New builds of E-Cycles are available for 2.79x and 2.8x for Windows. Linux and Mac will follow.
Changelog:
- 2.8x was updated against latest master with all it’s bugfixes
- 2.79x had a regression on multi-gpu setups causing slowdown. Speed is now back to normal.
- 2.79x quick settings panel now also has 2 new options: persistent data and transparent shadows. Those were already available, but are now easily accessible
3 Likes
Thanks BB!.. But is it normal for the splash in EC to say Hash: unknown - Branch: unknown?..