Cycles vs Octane speed comparison

Support Lighting and Rendering
#1

I did not intend for this to be a benchmark scene but I just have a few issues with cycles 2.8 that I’m hoping are just me missing some settings. As you can see I have 6 of my 7 cards activated for both octane and cycles, and I’m using the GPU render.

Cycles

  • about 3x slower to clean up
  • when moving the camera the viewport is frozen so i dont get inbetween views if that makes sense. It only shows render when i let go of middleclick
  • absolute blurriness when the render starts for a good second where i cant really see anything at all

Somehow octane manages to stay relatively clean when moving the camera and this makes it so much more usable. I have tried setting all my bounces and stuff to 0 and I still have the same issue.

What am I missing?

edit: After more thinking after posting and doing some tests with just a box, this really isn’t about the cleaning up of the noise, its the fact that the render quality is so poor when I’m actively moving the camera. Is there a setting to help that?

#2

Hello have you tried changing the start resolution in blender? Go to the render tab and scroll down to performance. Try 256 or 512, since you have GPU’s. That will help alot with the blurriness you are talking about. Also restrict the viewport render to the camera border outline by pressing CRTL + B and draging it to the view of the camera. Right now you are rendering more than the final camera resolution since you are rendering outside border of the camera as well.

#3

Hey man, I appreciate the help. It is definitely better with that but is still not what I’m used to coming from octane… it also seems to come with quite the cost of updating the scene :frowning: there is a very long process of “updating scene BVH” “updating lights” etc whenever I create a new object or change the bounce settings or something.

But its definitely an improvement! Hopefully there’s some other magic things like that?

#4

How much do you have your preview samples set to?

#5

just 16 which is not even close to cleaning up that gundam scene. Just using a simple box scene is fine though, making new geo doesnt impact the updating bvh and lights stuff much at all. Perhaps its just a limitation of blender actually having the geo in the scene where as octane brings everything in from disk

#6

16 is way too low you have 7 gpu’s crank it up all the way to 1000 samples.

#7

Yeah it cleans up fine with proper samples but my concern is more about the inability to see renders when moving the camera. Let me just show in video form :slight_smile:

This is octane: When I hold the button down to move the camera i can pan around the scene and see realtime updates

This is cycles: I’m holding down MMB and moving the mouse like crazy, it won’t show me anything until i completely let go

1 Like
#8

I think this is an overall behavior of cycles. It’s slower than other render engines.

2 Likes
#9

Hello, I usually check the simplify tab and set the AO bounces in 1 or 2 for my previews (also for the finals, if I do not care about the lack of realism), with only a 1080ti I get pretty good results in full screen, even with a start resolution up to 256 or 512 … (EDIT: I see later u have activated the 7 gpu’s already in the video :sweat_smile:)
sorry for my English

1 Like
#10

With all this said, as far as i know, the weak point of Cycles is the progressive refine render (what is what is used in the preview render) in comparison with tiled render, i hope all this will be adressed in a near future. @bliblubli commented something about trying to accelerate preview rendering in his branch E-cycles , so I have hope :slight_smile:

4 Likes
#11

Indeed, this is an example of my current working version of E-Cycles 2.7 while moving the camera:

Their is also a more affordable 2.8 version if you want.

4 Likes
#12

Thank you. Youve got a customer :slight_smile:

#13

Are you comparing Octane’s full path tracing kernel to Cycles’s path tracing. Or if you are using direct light kernel in Octane, ale you using simplify AO at 1 bounces in Cycles? Otherwise it’s apples vs potatoes comparison :slight_smile:

1 Like
#14

Yeah it was path tracing kernel in Oct. I will get E cycles up and running in next few days and post a new video with the comparison :slight_smile:

#15

Hey @alksndr :slight_smile:

I was wondering if you already have some results from comparing E-Cycles and Octane, I’m thinking on which of the two I should invest.

Thank you

#16

Hi, I do not have any visual examples but I experimented with it a bit. If you are going to stick in the blender ecosystem, go with e cycles. Its cheaper than getting an octane license and its super fast at rendering. If you are going with Octane standalone (which is what I ultimately did) then octane wins, simply because blender is not good at updating the scene. Theres a big delay when changing hdri’s, changing cameras etc and e cycles cannot fix that issue because its a fundamental blender problem. And you will have that problem if you use the octane plugin for blender as well. So if you like cycles and not having to export, ecycles is a no brainer because its 2-3x faster. When it comes to using octane standalone though, no other render engine has a chance. Its the best. I hope that helps you make the right decision!

2 Likes
#17

in 2.80 beta when we rotate a hdri we’ll get the “updating light”, i don’t understand tho, i can’t test right now but in 2.79b it’s interactive and there’s not the "updating light " thing

#18

2.79 is indeed faster most of the time. The UI is also much more responsive in big scenes and let cycles render at it’s full speed. 2.8 takes makes Cycles about 10% slower just by displaying it’s UI. Minimizing the window while rendering helps to workaround it.

#19

yes but it’s not bad

#20

I don’t think it’s bad. Just slower.