E-Cycles - The fastest render engine for Blender. 3.2 release available now!

Good that we both want clarification, good also to know you are in the team. The points from my point of view are:

  1. The beginning: It was a request from one of your team member.

  2. How near from the core this member is, you can clear it in private?

  3. The method: It was meant as a cooperation with the FM team. I gave my contact to work with @Scorpion81 on it. So @Scorpion81 could have just give me his opinion directly and everything would have been cleared.

  4. a) What I do currently: just to make it clear, I ship a full version with E-Cycles because it’s the only way I found to have a good integration. I would really prefer to only ship it as a pure plug-in. It’s a lot more work for me to make 6 weekly builds for 3 platforms than shipping one packed add-on once a month for all 3 platforms.

    b) As I already said in PM, I have enough work and got regular requests for custom builds based on Mantaflow, sculpt branch, etc. I always redirected to the course in such case for people to learn how to do it and even combine as they want what fits to their workflow. I’m ready for cooperation if a branch maintainer(s) want.

  5. Cycles: the BF worked to allow people to even make Cycles closed source (Cycles started with GPL and was re-licensed on purpose by Brecht and all contributors with the agreement of the BF to add Apache, which required gathering the consent of many people, which is a lot of paper and legal work, so something you really need to be motivated to do).

    a) It means any coder who has contributed or is contributing code to the official Cycles version knows or is made aware his work can be used for closed source project when submitting the patches on the official tracker. So the mentality of official Cycles contributors is very different from the Blender contributors.

    b) This possibility is used by at least Cycles4D, the Poser and 3DSMax version and Rhino, etc. Do you prefer me to go to one of those package or do you think it’s more beneficial to have me teaching many people how to do it and have one of the fastest renderer available in the Blender ecosystem?

4 Likes

To test adaptive sampling, I build some scenes with volumetrics. Which one do you prefer as reference benchmark? Or do you have suggestions or blends which you think would better suit real use case.
1)

2)

3)

4)

5)

Render time is about 17 sec per frame on a 2080Ti at 1080p.

3 Likes

Actually I like the 4th one, just let it play out for another 90 frames…good combination of intense fire with lots of emission giving way to thick dense oily smoke, that’s usually where Cycles (and Octane/Blender) would choke and you’d have to greatly increase the samples to clean things up:+1: 17 sec a frame, now you need to release that like now :rofl: I could use it :wink:

2 Likes

Hi,
Got swapped emit / env passes in denoise layers.

This group node is just adding passes together, so it gives the same result, but I’ll fix it to make it look more clean. Thanks for the report. Très joli dessin au fait :wink:

Sorry for the late answer!

Optical vignetting doesn’t just make the corner of the image darker (which can easily be done in compositing), it also changes the shape of your bokeh as it gets closer to the edges of the image. This is what gives a cat’s eye / swirly look to bokeh:
image
Yes, you “can” get optical vignetting by modeling the lens in front of the camera, but it’s hard to control and time consuming.

The second thing is the colored bokeh texture. It allows to create more realistic chromatic aberration than in compositing, as it exaggerates the aberration in the parts that are out of focus. In compositing, unless you do your DOF using you Z-depth in there (which I wouldn’t recommend in this day and age), chromatic aberration usually just consists of blurring / offsetting the different color channels, from the center of the image. It doesn’t take depth of field into account.

You can get the shapes by modeling it in front of the lens, and I assume that you could get the coloration of the bokeh by having three offset colored shapes in front of the camera. But again, that’s not user friendly. Here was a patch to support bokeh texture that never got into Master: https://developer.blender.org/D1691

However, this isn’t enough as you would get the same bokeh coloration independent of the position to the focal plane. This is where longitudinal chromatic aberration becomes important.
This isn’t something that isn’t really supported by many render engines, but this adds a lot of realism to images. Fringing doesn’t have the same tint depending if it’s in front or behind the focal plane.

I am asking you as you seem to currently be the most pro-active coder for Cycles :slight_smile:

3 Likes

Good morning Mathieu (o;

I tried to change a blender file from Octane to E-Cycles…and spent some time due to the fact the the 3d viewport preview was much darker as the rendering…then I switched back to master branch and there the preview was fine…

Master branch 3d viewport preview (64 samples)

E-Cycles preview (64 samples)

Is the preset somehow affecting how alpha in principled shader is displayed?

Hi,
I guess you was using the 0516 build? There was a bug with alpha on principled in viewport that I fixed in the latest builds. I could maybe back-port it to 0516 if necessary.

Hi,
I’ll add it to my to do, but it may take some time. I remember there was a real camera add-on. How much of what you want is done by this add-on already if any?

None of this is done with that add-on, it only adds camera exposure controls and autofocus (also supported with more controls in my add-on Photographer)

These features really are rendering features that can’t be added only with add-ons.
Thank you for considering it at least :slight_smile:

1 Like

As requested with some frames more, critics are welcome:

I’m using the wisp fire shader in this case. I’ll try to make a compilation of reference benchmark files to monitor the render speed in different scenarios. If you have suggestions or blends to submit, you can PM me :slight_smile:

1 Like

New builds are available for all platforms.

  • The obj importer got reportedly fixed in Blender.
  • On the E-cycles side, the AI denoiser now correctly connects the environment and emission passes (final image is the same as before, but it looks cleaner in the node tree) . The nodes are also placed better now, thanks to @brent3d and @stephen_leger for the feedback.
4 Likes

Yeah WISP is gorgeous :+1: Freaking inferno! Good examples with lots of different aspects of smoke and fire in one simulation.

ROA (Random Object Array) addon has just been released for 2.8! I know off topic but I see it was mentioned on here at some point:grinning :wink:

1 Like

Except for Debian 9 on 1950X (o;

As all other Linux users reported that it’s now working, I was hopping Debian would also. I’ll continue to investigate why the June update has issues with Debian 9.

It is really odd…the denoiser library files are exactly the same size as the ones installed separately…

Hmm…maybe if I run it through gdb I might see something more than just segmentation fault…

Hmm…

(gdb) run
Starting program: /home/me/opt/E_cycles_2.8_v20190617_lin/blender
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
[New Thread 0x7ffff1843700 (LWP 126014)]

Thread 1 “blender” received signal SIGSEGV, Segmentation fault.
0x0000000004493efe in tbb::interface7::internal::task_arena_base::internal_max_concurrency(tbb::interface7::task_arena const*) ()
(gdb)

thanks for the report, it looks like a problem for Intel. Not the first time I get a problem with TBB…

Maybe it only likes Intel CPUs…especially since the new AMD announcements (o;

1 Like