E-Cycles - sales coming on 4th of April and Mac 2.8 version available

commercial

(mathieu) #547

All the features work, it’s 100% compatible with master.
Regarding scene preparation time, 2.8x has still some big changes pending in the depsgraph department (the part of Blender responsible to gather and trigger modifications and decide how to update the scene, not directly bound to cycles), so I’m waiting for 2.8 to stabilize before porting it there. But their is a beta 2.7x version already available which avoid recalculating the BVH to much, based on an old patch from Lukas Stockner. Actually for fly-through, it’s even computed once per video, so I render my archviz video at about 20-40sec per frame for Full HD :smiley:


(mathieu) #548

A new test on another scene, with DOF, glass, reflections, plants and still very fast clean image around 1-2 seconds on a single GPU:


(Lsscpp) #549

So all the E-cycles goodness is ported to the viewport preview? Wow!
I’m thinking how much gain would an Adaptive Sampling implementation would add to all this. Did you ever think to work on such a hard feature?


(Nekuine) #550

Yes, I am on windows !
I have already set a TdrDelay of 60s as I am using substance painter for texturing.
I did some other tests, I tried multiple size of bucket. The bug appears when I have 256256 tiles, and I had no issues with 6464. Once the crash happened, I can’t relaunch any render until I force blender ( by changing a parameter in my shading network and restart blender ) to recompute my textures.


(mathieu) #551

If it happens at 256x256 and not with 64x64, it still sounds as it would be a driver timeout problem. Windows 10 has a new tdr variable which is undocumented (to make it more fun I guess?), which produces the driver reset even if the set delay isn’t reach for some (reported, I’m still on 7).

This is on of the reason auto tile size is on by default, normally, using auto tile size you normally don’t even have to use the TdrDelay key. Normally, the best performance is reach with auto tile size anyway. If you want, you can also send a file per PM or Email to reproduce.


(mathieu) #552

Another dev is working on adaptive sampling. As we are still only a few devs working on Cycles compared to other render engine, I prefer to work on features that stacks with other’s work. BF work on OpenCL, I on CUDA, other on CPU, denoising, adaptive sampling, etc. It makes an awesome product in the end :slight_smile:
Actually, the viewport is perfect fit for adaptive sampling as it samples the whole image at once, tiled rendering is trickier to get right. Maybe making progressive final render work faster would allow to use the same simpler adaptive sampling implementation for both.
But anyway, waiting 1 to 2 sec to see my scene makes me already happy with the current state :slight_smile:


(mathieu) #553

Another test with loads of lights, takes a bit more time. Still about 3sec to clear the noise with complex materials and reflections.

Does anyone know a good screen capture soft? I first used OBS studio, image quality is good but it cripples viewport perf. Then Licecap, very lightweight so the viewport perf is ok, but it makes banding/noise due to GIFs limitations. Or do you find the videos ok?


(DDB) #554

wow !
any differences with pre-rendering times ?


(yfile) #555

You don’t need any additional screen recording software. Quicktime on every Mac does it very well - just click REC button and mark screen area. All you need is E-Cycles for Mac. :slight_smile:


(giacometti777) #556

Shadowplay from Nvidia is very high performance and built into GeForce Experience. Don’t know if thats the type of solution you are looking for, though.


(mathieu) #557

2.7x has a beta version for pre rendering time indeed.


(mathieu) #558

I’m on it, patience :wink:


(Eric Klein) #559

What your are doing with Cycles improvements is great and want to see it further develop that’s why I have supported both e-cycles and the course.

Eevee is also great and we are fortunate to have both options. I use both Cycles when I need full accuracy on my render scene. Eevee when full accuracy is not needed I can save considerable time in large size render, animation, volumetrics, etc.

Using your same scene from Evermotion the Eevee viewport with high quality settings and is very fast to get completely clean render. A final render at 1080p took 10 seconds. See video below.


(BlackRainbow) #560

Just to make a few things clear. Do you use daily updated blender builds for E-cycles? How often updates on master build get into the e-cycles?
Archvis tests are amazing, but are there any speedups for interior render with mostly indirect multi-bounce lighting?
Other than that i’m definitely getting this for my next project! Especially with adaptive sampling on the way.


(mathieu) #561

I add the master improvement at least once a week, often it was twice a week.
New features come every month, the next one will be most certainly the viewport enhancement.
It works whatever the number of bounces are as far as my tests go, it is about 2x faster to get to the same noise level as master.


(mathieu) #562

I respect the work done, but personally:

  • with E-Cycles, I can switch from game engine quality level for seconds render to V-Ray quality by just moving the bounces slider. In Eevee, if your client says it sucks, you are good to move everything to another renderer, which is not thinkable when you have some minutes to meet the deadline. The complete lightning breaks as there is no way yet to make lamps behave the same in Cycles and Eevee. And I think lightning is one of the most important part of a render as it defines the mood.
  • the quantity of available assets for Cycles is just huge and work instantly.
  • Glass and vegetation looks way better in Cycles (self shadowing with sunset light though the leaves look gorgeous for exteriors)
  • Eevee needs scene-level tricks (objects placed in scene). From experience, clients change their idea every other hour, which breaks such tricks. It brings another hassle of set of objects to maintain.
  • RTX may solve this, but then it will only be for RTX card owner. E-Cycles works even on GTX 600 series from 2012 (7 years old).
  • Cycles easily handle thousands of trees, bush, grass, etc in viewport and final render. With Eevee it’s just impossible and it will stay so as it’s a rasterizer. I like to have one engine for all my scenes.
  • E-Cycle is 100% compatible with Cycles. With Eevee, you have to relearn a lot of things.

So learning a new engine, convert all my assets, worry about breaking tricks or a client that would want higher quality I can’t deliver, to only render simple to medium level interiors and even then only spare 10 seconds at render time is not worth to me. 20seconds for full HD render with E-Cycles is more than acceptable I think.


(Eric Klein) #563

I agree the quality of Cycles is great. Even with E-Cycles I have a number of interior scenes that to get a clean final render specially at 4K, animation or volumetric takes a lot longer than Eevee. I know tricks of reduce AO bounces even then is still not acceptable time or quality wise. Conversion from Cycles to Eevee assets is pretty compatible. The changes are mainly in lighting, reflection and GI.

I hope in the future with your work and Blender foundation can keep making Cycles better and faster and I thank your effort in improving Cycles with E-Cycles

My point is that personally is great to have to option to pick Cycle or Eevee depending on my rendering needs.


(Lsscpp) #564

Oh that a big news for my ears!
Where did you get this insider info?

Yes, wise move, less double work: optimize Cycles optimizing human resources :wink:


(Metin Seven) #565

I had the same fear until I recently switched from macOS Mojave to Windows 10. If you go for a solid PC and the latest Windows 10, the transition will be quite smooth, to my experience.

I can now enjoy using an internal and fully supported NVidia GPU again, use CUDA, the latest OpenGL and OpenCL updates, and install useful Blender add-ons that aren’t available for Blender macOS, such as OpenVDB Remesh.


(mathieu) #566

Well, as you say, it’s insider info :wink: .