Corona Render

[rohandalvi]

hi,

http://corona-renderer.com/

I dont usually post about new renderers, but this one really caught my eye.

Good enough to make me go back to 3dsmax after 10 months

It's a new renderer , still in alpha stage called Corona. It's a plugin for 3dsmax and it's currently free. It's also really stable, I have been using it for a week and it hasn't crashed even once.

Now the big question, why post it on odforce. Primarily because it's essentially a Pathtracer and it's ridiculously fast. Frankly i have never seen a path tracing renderer running on CPU, not GPU, go this fast.

You can never really compare render speeds between different renderers, unless they use roughly the same technology. Now, I believe that Mantra PBR is also a pathtracer, ( If I am wrong, please correct me.)

So I decided to render roughly similar scenes in Mantra and Corona. The model is pretty simple, Its a toy truck, with glossy reflections on pretty much everything, and two really massive area lights. Since Corona was happier to do it with two planes with a constant shader, that's what I used in 3dsmax. I am posting the images below.

The interesting thing is that the ray depth in corona is 25. It has a unified depth value for reflection, refraction and diffuse. In mantra, it was 10, 10 and 3.

Since corona is a progressive time based renderer, I gave it 6 mins to render. You can see the images to see how long Mantra took to achieve similar quality.

So anyone who has access to 3dsmax you should definitely check it out. You need to register on the forum to get access to the renderer.

regards

Rohan

P.S. personally I think Sidefx should just hire the developer, that way I don't have to go back to 3dsmax.

Edited November 10, 2012 by rohandalvi

[gui]

Cool! I hope this kind of things makes the guys at sidefx to increase mantra speed!

But, one thing is render just one image, other is render a sequence. If you wanna continue with your tests, make an animation and render it with motion blur to see how corona will behave.

[lukeiamyourfather]

The performance of GPU accelerated renderers is impressive. Equally impressive is their list of caveats like hair, motion blur, displacements, instances, volumes, programmable shaders and geometry attributes, graphics card memory limits, and so on. I don't think I've ever worked on a show or commercial that could be done with a GPU accelerated renderer. A few shots here and there but overall they're just not ready for production. The tasks they are superb for are product renderings and architecture since those often don't need more advanced rendering features like volumes and hair (or any of the other stuff that doesn't work with GPU accelerated renderers).

[symek]

The performance of GPU accelerated renderers is impressive. Equally impressive is their list of caveats like hair, motion blur, displacements, instances, volumes, programmable shaders and geometry attributes, graphics card memory limits, and so on. I don't think I've ever worked on a show or commercial that could be done with a GPU accelerated renderer. A few shots here and there but overall they're just not ready for production. The tasks they are superb for are product renderings and architecture since those often don't need more advanced rendering features like volumes and hair (or any of the other stuff that doesn't work with GPU accelerated renderers).

Corona is a CPU engine, still a couple of questions about features set rise, like programmable rendering engine, primitive versatility, motion blur and the rest of a gang mentioned by Luke. Another point is methodology, the scene you posted really doesn't say much about any renderer. Same as row parameter setttings (ray depth).

Could you post a hip file, to check out Mantra settings?

Edited November 10, 2012 by SYmek

[lukeiamyourfather]

Corona is a CPU engine...

My bad, the eyes trick me and I thought the original post said "GPU not CPU" but it was the other way around.

To sum it up flexibility and controllability are more important than performance to me. If I can have both that's great, but given one or the other I'd rather be able to get a shot done slowly than not at all.

Edited November 10, 2012 by lukeiamyourfather

[symek]

To sum it up flexibility and controllability are more important than performance to me. If I can have both that's great, but given one or the other I'd rather be able to get a shot done slowly than not at all.

That's for one, secondly 45 minutes is a timing PBR renders beautiful production frames in, including fur, not that basic example, thus I asked for a scene.

[rohandalvi]

Hi,

As it's still in alpha, there are a lot of things missing. Right now it doesn't even render particles let alone hair and fur. Also I believe they are aiming at architectural visualization as a primary market as a start so I don't know if a programmable render engine is very high up on their list. I dont think they are aiming for the film and vfx market in the beginning.

It does , however, have a proxy(render instances) and scattering system in place to do vegetation and stuff.

But there is no getting around the fact that Mantra is slow. The fact that corona took 6 mins when mantra is taking close to 40 mins, means that Corona is doing something right.

If Mantra can be sped up to the point of corona( for simpler renders), Houdini can be a used in a lot more markets. Because markets like Arch viz and product renders dont really need any of the stuff that film renderings require, like hair and fur, motion blur or programmable shaders. DOF can be easily faked in any compositing software.

I have always thought that Houdini would be great for Arch Viz. Once the building has been modeled, populating the scene and environment generation would be so much more easier in Houdini. But, there is no getting around the fact that for this kind of work Mantra is definitely not the best candidate for those sort of renderings especially when you have something like Vray around.

But if you have a renderer like Corona which can come close to vray like speeds while doing path tracing, it really changes the field.

And if Corona can do it so can Mantra. I have full faith in the wizards working at Sidefx.

I am posting a few more renders from Corona. They are all between 30-55 min range, but mostly towards product renders and arch viz. And with the quality I have been getting, Corona is certainly production ready for those two fields.

I am also attaching the hip file so you guys can take a look at it.

regards

Rohan

dump truck.rar

[Erik_JE]

You forgot to lock the file node.

Just checking your mantra settings they are way off from what is optimal.

Edited November 11, 2012 by Erik_JE

[rohandalvi]

hi erik,

Sorry about the file node. That's why I added the truck.obj. Incase I screw up. Something I am usually prone to do.

Also It would be great if you could post a render which has better settings and render time. I still sometimes struggle with PBR as to the settings. Mostly I just play with the Samples and the min/max settings. I believe that the max settings is just an upper limit which doesn't really have much of an effect on rendertime. Which was why I set it to 64. But If I am wrong , do let me know.

The idea was to get it as clean as the Corona Render.

regards

Rohan

[Erik_JE]

This was 9 min 40 sec on my machine. i7 2600k.

Not saying mantra is perfect but getting images of that quality dont take 45 mins.

EDIT: Also i totally missed dump truck.obj was in the rar before

truck.hipnc

Edited November 11, 2012 by Erik_JE

[Erik_JE]

Here is with gamma 2 as well. Did not have time to tweak the lights or colors fully to work with it but you can see the background is less noisy.

Same rendertime. One more diffuse bounce.

truck.hipnc

Edited November 11, 2012 by Erik_JE

[symek]

I dont think they are aiming for the film and vfx market in the beginning.

(...)

But there is no getting around the fact that Mantra is slow. The fact that corona took 6 mins when mantra is taking close to 40 mins, means that Corona is doing something right.

I don't know anything about Corona, looks like a decent render (as many these days of equal and free access to knowledge and opensource components...) but you are missing the point. First, the market by choice of both renders has a crucial impact on what both of them will be good at, and the more specialized they are, the more differences in particular scenario they will have. This is exactly the (theoretical) reason, why Corona might (theoretically) be better at rendering static, triangles solely scenes, with no material overwrites, no displacements, no geometry attribute driven shaders etc, no deformation blur, AOVs etc etc.

Theoretically, because.... your comparison is inaccurate. This scene can be rendered in Mantra in less than 10 minute, with comparable quality on my old dual core laptop (Core Duo T9500) Divide it by at least 2 (or 4 actually) to get the spec of your Intel i7@2.66 and note, that quality of my try is slightly higher (but the resolution little lower).

ps

your renders are faulty, because you seem to be lighting and rendering in sRGB space. I don't know how Corona handles this, but generally speaking physically based renders are sensitive on color space issues. I had to adjust your scene for linear color space workflow, which significantly helps Mantra to resolve sampling noise.

[EDIT] Oh, I did it try on a workstation too (6 years old Xeon 5355 2x4x2.66Ghz):

Generating Image: /home/symek/Desktop/truck_mantra.jpg (768x431)

Plane[C]: Cf+Af[4] (16-bit float)

Render Time: 19:10.37u 2.83s 2:31.02r

Memory: 824.17 MB

Edited November 11, 2012 by SYmek

[rohandalvi]

hi,

I am really glad that posted this here, because I got to learn some really nice things I didn't know about Mantra.

Firstly, Erik thanks about the Noise level parameter, never really tried that before. Got my render time down significantly, but what was 9.40 on your system became 30.21 on my system. I guess there is a pretty big difference between the i7 920 and the i7 2400K.

SYmek, Your render looks fantastic. pretty close to the result i got with corona.

Could you explain about the whole sRGB and linear space stuff. I know what they mean but where do you access them from in Houdini. Also would be better if you could just upload the hip file, so I could check out the changes you have made.

No need to lock the file node, just upload the hip file I will reload the File node on my end.

SYmek, I was basically just comparing the speed of a Corona to Mantra on a simple enough scene which wasn't dependent on any sort of attributes. But if the speed difference is just mainly due to my lack of knowledge, then that is really good news, because it means that I get to learn something new.

regards

Rohan

[altbighead]

hi,

I am really glad that posted this here, because I got to learn some really nice things I didn't know about Mantra.

Firstly, Erik thanks about the Noise level parameter, never really tried that before. Got my render time down significantly, but what was 9.40 on your system became 30.21 on my system. I guess there is a pretty big difference between the i7 920 and the i7 2400K.

SYmek, Your render looks fantastic. pretty close to the result i got with corona.

Could you explain about the whole sRGB and linear space stuff. I know what they mean but where do you access them from in Houdini. Also would be better if you could just upload the hip file, so I could check out the changes you have made.

No need to lock the file node, just upload the hip file I will reload the File node on my end.

SYmek, I was basically just comparing the speed of a Corona to Mantra on a simple enough scene which wasn't dependent on any sort of attributes. But if the speed difference is just mainly due to my lack of knowledge, then that is really good news, because it means that I get to learn something new.

regards

Rohan

Stick to Mantra if you want to render animation sequence with hair,fire,smoke volume and shit loads of geometry.Every week , there is a new fancy renderer popping up and they come and go.Mantra doesn't and you can thank me later.

[old school]

Hi Ronan,

What a perfect file to warp and twist a render's performance. Super simple geometry with no surface complexity what so ever. Simplistic lighting scenario. Perfect set-up to turn Mantra's PBR defaults sideways but if you know a bit about how to approach such a scene, you can dial it in and get super reasonable render times out of Mantra.

Just looking at your file, yeah you had the primary samples jacked which is what I find most everyone does when they first try to get clean PBR renders. I really want to have a reorganized interface in a Mantra ROP tailored to just do PBR.

My approach with PBR and Mantra these days is to set the primary Pixel Samples as low as you can to resolve the geometry detail itself and if there are fine displacements or high frequency textures, then and only then will I start cranking up the primary Pixel Samples if I can't resolve that "primary" detail. I call these "primary" as they are the bare minimum that Mantra will fire at the given bit of surface under the current pixel being shaded. These are the first set of rays that find geometry (including fine curves and displacements), resolve geometric detail and run shaders to draw texture maps and procedurals.

After that, secondary rays are fired at the same bundle amount set by Pixel Samples when the noise threshold hasn't been met. The Min Pixel Samples I rarely set above 1. The Max Pixel Samples defaulting to 9 I don't change unless I start lowering the noise threshold below 0.02 or 2 percent variation in the returned pixel samples. The max Pixel Samples is a maximum threshold for number of Pixel Sample passes to perform in order to reduce the noise to your given noise tolerance. Either you run out of secondary ray multipliers on the Pixel Samples or you reach your noise threshold.

When rendering with PBR, you must set the gamma to 2.2 or use a proper sRGB lut to compensate for your monitor OS settings. It assumes that your images will be color corrected with a gamma 2.2 set. If not, you will adjust your lights for things to look good and that will cause your darks to be artificially too dark with the result being much more noise. I wonder if this given render engine is Fisher Price'ing the linear lighting process by doing this all behind the scenes for you. I won't tell you the amount of heat we'll take in Support if we ever tinker toy'ed the interface...

Pretty simple. Chase the rays in the darks where there is more noise and fire as few rays for the areas swimming in lots of light. Now for some tests to see this in action. In the images below, look at the shadow under the dump as well as the yellow of the dump on the rear as trouble areas where the noise seems to be most obvious.

My test mule is a MacBookPro core-i7 2.3GHz 4 cores with 8GB of memory.

I always set the Color Space on the Mantra ROP to Gamma2.2 to help get PBR chase more light rays in to the dark occluded regions.

I also left the Diffuse bounces to 3 as you have set them and no indirect Photons used.

Time: 3m01.374s

Pixel Samples: 3x3

Min Ray Samples: 1

Max Ray Samples: 9

Noise Level: 0.01 (one percent)

Notes: By rendering out the "level" export plane, I can see that with noise level set to 0.01, in the dark regions the trace level hit around 9 so the number of rays were 9*3*3=243 in the dark shadow areas. On the more direct illumiated surfaces, it was at 1 or 2. The Ray Variance Aliasing allows you to use the noise percentage threshold to have PBR chase rays where you want them to go.

Time: 3m29.139s

Pixel Samples: 3x3

Min Ray Samples: 1

Max Ray Samples: 10

Noise Level: 0.01 (one percent)

Notes: This next render has the Max Ray Samples bumped up only one stop and the render time is a bit longer. This tells me that the previous image hit the Max Ray Samples before the noise threshold was satisfied in more areas than this render. In this image, with the extra bundle of 3x3 primary samples, the noise threshold caused another multiple of rays to be cast in the dark shadow regions and most likely the noise threshold was met in more areas of the image.

Time: 9m46.193s

Pixel Samples: 3x3

Min Ray Samples: 1

Max Ray Samples: 32

Noise Level: 0.01 (one percent)

Notes: One third longer render from the previous even though the Max Ray Samples is set to 32. I am now pretty much guaranteed to have reached my specified noise threshold limit of one percent (0.01). At 9m a render, this should be the absolute longest render time for this kind of an image. If you are getting anything longer than this with the given hardware, then you jacked the pixel samples too high.

The only thing reducing the noise now is to reduce the noise threshold even further or investigate the use of indirect photons to help with calculating irradiated light and reduce secondary bounces.

Time: 4m36.849s

Pixel Samples: 2x2

Min Ray Samples: 1

Max Ray Samples: 32

Noise Level: 0.01 (one percent)

Notes: So now lets put the knowledge to a test. Given that this is a real simple model with little if any geometric detail and the edges are all fairly smooth, we should be able to reduce the primary Pixel Samples and still get a nice clean render.

Reducing the primary pixel samples to 2x2 in this specific image with very little surface detail really doesn't have much effect on the final image quality and with Max Ray Samples at 32 and noise at 1 percent, still gives you very nice results with indirect lighting. Now if this model had displacements or fine highly detailed textures, I'd probably have to bump up the primary Pixel Samples to 4x4 or 5x5. You just gotta play with it.

Time: 4m58.302s

Pixel Samples: 2x2

Min Ray Samples: 1

Max Ray Samples: 32

Noise Level: 0.005 (0.5 percent or half of the above images)

Notes: Pushing things to the logical limit, let's reduce the noise threshold in half and see if we can chase more pixel sample rays in to the shadows to clean things up there. As you watch the render progress, the nicely lit areas render quickly but when the bucket lies in an area of shadow, things slow down as they should. Now if you naively jacked the primary samples, you'd get this even overbearing overhead. Remember, chase the noise!

So the render time didn't increase that much indicating that we are bumping up against that 32 Max Ray Sample threshold so now you can carefully increase the Max Ray Samples until the noise in the darks are gone with minimal increase in render times on top of this.

Time: 3m21.05s

Pixel Samples: 2x2

Min Ray Samples: 1

Max Ray Samples: 32

Noise Level: 0.005 (0.5 percent or half of the above images)

Added Indirect gilight to the scene to help cache indirect light at default settings

Notes: Same settings as the previous render but significantly faster, smoother and with more indirect light. Sweet.

Adding the indirect light does have an additional overhead in calculating the photons but not that bad. It does become invalidated in the IPR viewer if you change a light or a surface parameter, but within reason when tweaking subtle light values and colors, you can plow ahead knowing that the indirect photons are not quite perfect but close for tweaking.

Mistakenly many think that using indirect Photon Maps is primarily for speed with less noise. Well yes and no. I use them primarily to get at the final total limit indirect diffuse contribution in the scene. Note the yellow in the shadow under the dumper and red under the cab in this render. You'd have to crank the indirect ray bounces much higher to get this otherwise.

So this is one way to dial things in with PBR. First get the primary samples to resolve the primary direct lit surface detail to where you want. Then add indirect lighting by managing the max ray samples and the noise level on top of the base Pixel Samples. Simple and effective.

[magneto]

Wow Jeff, more posts like this please

[Sifis]

Excellent post Jeff, we always appreciate tips for more efficient rendering. Keep sharing your knowledge!

[symek]

My approach with PBR and Mantra these days is to set the primary Pixel Samples as low as you can to resolve the geometry detail itself and if there are fine displacements or high frequency textures, then and only then will I start cranking up the primary Pixel Samples if I can't resolve that "primary" detail.

Practically speaking you will hardly ever find production frames without motion blur and/or depth of field, thus you can safely get used to that a pixel samples will be at a level 8-12 at least.

[Mzigaib]

So this is one way to dial things in with PBR. First get the primary samples to resolve the primary direct lit surface detail to where you want. Then add indirect lighting by managing the max ray samples and the noise level on top of the base Pixel Samples. Simple and effective.

Thanks you very much for the really helpful info, that's really awesome information, since I am here I am going to ask for more tips .

I used the technique described above and it's really effective on non blurry reflective materials which is awesome! I get a lot of speed and very smooth results than just trying to simply crank up the samples but It seems for blurry reflective materials the rules change a bit unless you increase the pixel samples I always get the same noise result from them, I can be doing something wrong off course, so when I have non and blurry reflective materials on the same scene decreasing the pixel samples works really well for most of the materials except for the blurry reflective ones and if I increase the pixel samples I got the quality that I want but the render times increases exponentially a lot. Does it make sense?

How would be the workflow in this case? is there a way to set the sampling control per object basis? Any tips to optimize the speed in this case?

Thanks.

Edited February 17, 2013 by Mzigaib

[gui]

I have the same problem as Michel, but with volumes, when using raytrace. Hope the solution is the same....