Is this Cycles ? Are you highlighting a specific improvement ?
Huge difference. There is a great perspective here. I definitely want it.
It is Cycles indeed and E-Cycles, the stills are full screen, so you have to click them to really compare. The goal is to make Cycles viewport as fast or even faster than Eevee. Eevee is fast at defaults, but is pretty slow when you push quality. So I modified Cycles to make it very fast. But I want to gather peopleâs opinion to know if the speed and quality is enough for them.
2 Likes
Ok is this kind of a preset ? Or a deeper modification ? From your screenshots it looks clearly more noise-free.
It uses the new sampling and features of E-Cycles smartly, the user just has to activate viewport render. Of course, more perf can be reached by tweaking the scene, but focus is to make it fast for professional, so out of the box, to spare human time.
Ok for anyone else wondering, this is a custom Cycles build, see here :
https://blenderartists.org/t/e-cycles-render-interiors-under-a-minute-with-cuda
Interesting to say the least !!
1 Like
amazing work ! continue like this this is just mind blowing !
1 Like
Wow, awesome stuff. Please put this in the course and anything/everything that improves render speeds. Thank you very much. 
2 Likes
One more vote to added to the course. What I like the most is that you have avoid doing the cycles pre-processing when rendering a new frame. The next step is to add the intel denoiser at the end of the viewport rendering like LuxCore render has done. Check this video. Luxcore render ODIN integration.
Merged threads.
a test with DOF and the upcoming viewport enhancements in E-Cycles:
Itâs done as usual with a single 1080Ti.
1 Like
Amazing result here !
I amazed by the result of your work ! I just bought your product for a month to try out, the very 1st render I tried seemed to work well, but after this one i canât achieve another render, I got the " Cuda error : Launch failed in cuCtxSynchronize(), line 1740" message. I am working on a 1070 maxQ design. Do you have any idea where it can come from ?
Thanks !
Will buy after that viewport enhancement is in, looking good! What you have here is looking a lot like Octane speeds. Does micropolygon displacement still work and all other general cycles features? Have you been able to make any improvements to compiling the scene? I have mega slowdown if say in a mil poly scene I try to create a cube, it takes so long to âupdate scene BVHâ and âupdate lightsâ in my 2.8 cycles so curious if you also have solved that. Looks great!!!
1 Like
Make sure you check the âReadme first windowsâ file on gumroad. Iâm not sure thats causing the issue you are having but I wanted to be sure you saw it.
Yes, indeed, it happens on some windows configuration, so I guess you are on windows? Their is a readme file explaining how to solve the bug called âReadme first windowsâ, it should be the first file at the top of the download page. Tell me if it solves your problem
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 
1 Like
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:
5 Likes
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?
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.
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.
1 Like