Arnold's new renderview (some nice features hope to see in V-Ray)

[^Lele^]

Agree Lele. I posted in another thread some simple test drive results with PRMan RIS, V-Ray RT, and Arnold here. Not a heavy or interior scene at all but I guess it still means a little bit in terms of how good the viewport is communicating to the render view in each renderer?
I guess it's really hard for a heavy interior production scene to be decently responsive in viewport and othe panels when CPU is crunching anyway. Still, if Chaos Group can figure out a way to smoothly fuel back and forth some CPU juice back between VFB rendering and viewport/panel when user inputs are detected, it will be fantastic. How about a tick box to decide if the user want the RT to go full speed or throttled for better viewport/panel responsiveness?

Well, iRay seems to be using a totally different engine for their interactive renders than the production one(s), tuned for speed at the expense of caps imposed to one or the other feature (GI bounces/reflections and so on).
That's a solution for interactivity (along with lower priority cpu/gpu usage, i agree), but as far as i can tell also a recipe for destruction, if the scene is complex enough, with results potentially very different in final renders than they could be gauged from the interactive.
Six of one, half a dozen of the other. ^^

[jasonhuang1115]

Well, iRay seems to be using a totally different engine for their interactive renders than the production one(s), tuned for speed at the expense of caps imposed to one or the other feature (GI bounces/reflections and so on).
That's a solution for interactivity (along with lower priority cpu/gpu usage, i agree), but as far as i can tell also a recipe for destruction, if the scene is complex enough, with results potentially very different in final renders than they could be gauged from the interactive.
Six of one, half a dozen of the other. ^^

Isn't iRay a GPU-based raytracer? I presume when GPU is crunching for rendering, the CPU can be used for keeping viewport and all other panels fairly interactive...I could be totally wrong tho...

[^Lele^]

We should ask the RT team for clarifications (I would surely misuse the terms.), but i believe if your GPU is entirely occupied, you wouldn't even be able to see the mouse move (the CPU may well know where it is, but still has to ask the DX acceleration to draw it, and that's through the video card...
iRay can though use either, or both at the same time.
However, the interactive sampler isn't the fully-fledged, final render one (which comes with two options for caustics and architecture, either of which can change the look fo the render quite dramatically, and not necessarily for the better.).
It's a cut-down version with limited effects and bounces, so to give a good general impression of what's happening even in complex interiors.

This said, the speed difference in BF GI tracing between Arnold and iRay (i won't mention V-Ray to add -little- weight to my unbiasedness in this) is in the order of four times (in favour of iRay) when i last tested them (that's last week.).
Arnold's issues aren't in the quick preview window, imho.

EDIT: let me explain the above a bit better, Blago correctly pointed out that if i tested iRay with CPU+GPU rendering, and Arnold with just CPU rendering, i was comparing apples to oranges, and doing quite the disrespectful service to Arnold.
Guilty as charged, i replied, in that this was not meant as an outright benchmark of the raytracing code performance, clearly invalid as ran on two different hardware setups.
But i also defended the comparison within the frame of "out of the box" usability.
Maybe Arnold is aimed at a different market, and that's why they show the feature on characters, but the iRay preview window does what they show on their videos, on my simple workstation, with architectural interiors (say, 15+ effective bounces of GI are often needed), whatever corner it cts to get there.
Arnold's preview window in that situation becomes unusable on the simplest of scene (geometrically) because it's ill-suited at handling multi-bounce GI (then add glossies, sss, and so on) due to its inherent design architecture, which is non adaptive (so one gets a ray explosion as each bounce shoots the square of the incoming rays...).

I shall endeavor to test the two side-by-side in as close a setup as possible (not just CPU or GPU), but the fact remains: when i compare the most common renderers out there (i am curious, and tested them all quite thoroughly. But say us, iRay, rMan, to name three) to Arnold, the test goes in one direction only: i have to reduce the features used by the other renderers to match the ones in Arnold.

P.S.: outlandish and arbitrary my claims may seem, i invite you all to download the demo versions and try them out for yourself.

[jasonhuang1115]

The asset used in the demo video is available here with the HDR env map. It's easier now to set up an apple to apple comparison to check the performance and features.

EDIT: honestly, I care less about the raytracing performance (in terms of how fast the render is cleaned as long as it's a significantly slowdown) in this case but more interested in the interactive performance, less scene re-exporting, and couple features.