Help With Speeding Up Render

[Anti-Distinctlyminty]

Hi all,
I was determined to get a clean render out of mantra for this sequence, which I sort of managed to do, but the render times are just too high. I'm looking at over 5 hours per frame for something that is quite simple, as you can see from the attached screen shot.

I could get something that looked reasonable, but to stop the highlights crawling between frames I just had to turn pixel samples up high. Nothing else seemed to sort out this problem (light quality & reflection quality just didn't work). The particular point I focused on was an area on the glass, on the centre of the image at the top - there's a small rectangular reflection from one of the lights, and where this went over the inner lip of the glass there were just always fireflies. The only thing that removed them was cutting the colour limit to 4 (from 10) which dulls the image, and turning up pixel samples to 12x12, which everyone seems to think is very high.

I feel there's something I'm missing when it comes to getting a clean render. I've attached the hip file which contains the geometry and the hdr so, if anyone is able to help, just open the scene and see if you can get a better render time than I did. 

Petri_Dish.7z

[Guest tar]

16.5 probably helps with this- just wait a day if you can.

[Anti-Distinctlyminty]

I did see something in the list about noise from PBR reflections...but still, anything learned fom optimizing this should still help overall.

[Skybar]

I've solved crawling highlights before by adding the "jitter" parameter to the mantra rop and turning it off. It was a while ago last time so dont know if anything has changed, but you can try that. 

[Anti-Distinctlyminty]

Sadly, that didn't really work. I may send the hip into sidefx....five hours is just too high to be usable. 

[Guest tar]

Did you hear back from SideFx? Looking into it it is very slow as those highlights are a refractive reflection through two surfaces. A wacky Redshift render got a clean version in 1.30min on a 1080ti.

[Anti-Distinctlyminty]

No, I've not sent it in yet as I've been a bit buried...I'll do it now. 

Was your redshift render time 1m 30s or 1hr 30m? :/

I tried in 16.5 and it was still > 5 hrs.

[Guest tar]

1min 40sec.

Here's the file - you can get a demo of RS and check it out. The materials are all generic, nothing tweaked.

Test_RenderRS.hiplc

[Anti-Distinctlyminty]

That is quite fast

I did get a reply from SideFX that was quite useful which I shall paste here:

Quote

Hi. The the hilight flickering around the area you outlined isn't necessarily suffering from noise, but rather aliasing caused by tiny geometric details that are being undersampled. ("Removing Noise" guide on the documentation won't help too much with those cases)
    
    This is particularly problematic when roughness on the material is low. Increasing light sampling quality won't be very effective because, due to low roughness, all the variance samples will shoot towards the same/similar direction, thus giving more or less similar results. The only effective solution is to increase camera samples so that eye rays don't miss any geometric detail.
    
    That said, there are a few workarounds that can help if slight change in look is acceptable:
    1. make area light sources larger (reducing energy per area, and giving bsdf samples better chance to connect with the light source)
    2. increase roughness of the materials (will make variance sampling more effective. you could measure SOP to compute curvature and feed the attribute into roughness parameter to target only the problem areas)
    3. change the geometry so that the corners are less sharp (eg if you're using polybevel, increase the bevelling radius)

 

Marty, I see that your image doesn't have the offending area light highlight that was the problem in the original...but I'm guessing at 1m 40s it's not going to be much of an issue. I re-uploaded the hip file incase things were missing from the first one. I think redshift is worth looking into, even if just getting a single machine license to deal with these individual shots. 

Petri_Dish.7z

[Guest tar]

I'm checking a rendered sequence right now but by setting the material as thin walled it kind of has that particular highlight. The render times are now at ~4min 20sec as the samples are a lot higher. The uber cool thing with Redshift is that you can always add another 1080ti and the render times are essentially halved. Nice to know

Edit: added a revised setup with RS lights.

Test_RenderRS_2.hiplc

Test_RenderRS_3.hiplc

Edited November 15, 2017 by tar

[Anti-Distinctlyminty]

That is good to know. I need to look into Redshift it would seem :/

Although I'd still like to optimize the mantra version to see how low I can get the render times. If this kind of thing pops up again I should be somewhat prepared.

[davpe]

this is my take on Mantra render. try to open attached file and render mantra2 ROP. seems like classic shader does a bit better job with ray sampling (at least in this case) so I used that one instead of principled, with exception of the glass dish which looked considerably better with principled (pretty sure you can achieve equally good look with classic but i was lazy ).  it should render apparently faster now but still not great, to be honest.

no image is attached as I never finished the frame for time reasons  I only tested stuff on interesting regions of the image. seems like gpu renderers are truly beginning to take over...

just for overview - at the end I somehow ended up with 6x6 pixel samples as opposed to your 12x12 and 1-24 ray samples as opposed to your 1-40, and turning off sss for liquid as that had minimal visual impact. lights in your scene were seriously oversampled with no gain to image quality. so i set them all back to 1. Also, there was an interpenetration of liquid and glass - some noise/slowness may be caused by that, but that's hard to say as I haven't run too many test renders due to "speed"  hdr for enviro light is different in my scene as you haven't embedded original one but that shouldn't make any noticeable difference in speed.

oh, and when fighting nasty speculars on edges you'll do much better if you allow rendertime subdivision (Render polygons as subdivision = on)

 

cheers, D.

Test_Render2.hiplc

[davpe]

or, have you tried biased gi-render? think it's worth trying.

I have changed my mind about this recommendation

 

Edited November 15, 2017 by davpe

[Anti-Distinctlyminty]

Haha, I hadn't tried it yet and I guess I wont either

Alas, the render times are about twice as fast, but alas the flicker is still present.

The interpenetration of liquid and glass was intentional as the shader surface priority should take care of that now. For this particular scene, it looks like more pixel samples is the only way :/

The original...

Edited November 15, 2017 by Anti-Distinctlyminty

[Anti-Distinctlyminty]

The annoying thing is that we have another renderer that we use, but were in the process of moving over to mantra, but the speed is a bit of an issue. Greater render times are acceptable generally because of all the other benefits, but this was insanely high compared to a clean (non-GPU)  render from the other package. I guess I have to learn to circumvent things that cause these issues. 

Still I did ask SESI to turn my query into a RFE. I'm sure they must know about this already, but hey.

[davpe]

hmm, this sucks .-/ but i mean, even if this is probably a poor performance compared to average competition, I've run into impossible render scenarios with any tool I have ever used. it's good to have an access to yet different rendering tool as well so that can ballance for shortcomings of the first tool. good news is almost any competitive renderer out here is great for doing such a nice scientific packshot or what the hell it is  

[Anti-Distinctlyminty]

Indeed. Hopefully I'll know how to better tackle shots like this in the future. Because we do science viz, glass items are quite common, so maybe a Redshift license will be the way to go.

As for Mantra, it can do things the other renderer just can not, and I love it for that...but most shots are not something out of the ordinary. I do wonder if mantra being so versatile is what makes it less speed competitive in certain aspects? But on the other hand the new single lobe sss is crazy fast, so...I have no clue.

[davpe]

yeah, as you said, Mantra is the best for many other things. But with Mantra not being the only product nor the most important one for sidefx, it must be hard to catch up with competition on everything. especially with gpu renderers stepping up, it must be a difficult dilemma whether to even invest time into further improving Mantra, which is, by design, something that seems to be on it's way to extinction in a few years as common cpu renderers have really nowhere to go much further (in my opinion). Many people are nagging that gpu renderers can't do everything cpu ones can, but looking at redshift, I think this argument is quickly loosing its ground. Reminds mi when old scanline renderers were gradualy replaced by GI. It took some time but at certain point, when GI solutions matured enough and hardware became fast enough, there was really no point for going back to scanline again (for 99% of users). Looks like it's almost time for sidefx to start developing a new gpu based renderer  

[Anti-Distinctlyminty]

They seem to be investing time into Mantra, so I'd guess it's not going anywhere. And like I said, in many areas it's really very capable...just this speed, gah. I'm curious what is actually killing the render time, considering the other renderer I was looking at was also using an implementation of the Principled Shader. And not all parts are slow...the new single lobe sss is super fast, so if SESI is listening, more speed hacks! 

AS for GPU rendering, hopefully SESI will be on that and give mantra that option, I don't think that's a crazy idea

Edited November 17, 2017 by Anti-Distinctlyminty

[davpe]

well, i agree my conclusions might sound a little bit exaggerated  don't get me wrong, Mantra has been my renderer of choice for a few years now and for me as a user it is certainly good and pappreciated that sidefx is making efforts to improve it. 

Now I'm no expert in programing render engines but it looks like the basic math how to compute lighting is more-less the same for all the pathtracers. So I assume the biggest impact on how fast a final image can be computed has either importance sampling (and this is where Mantra is certainly not that great) or various filtering methods that can take a few scattered samples and make it look good enough (so we're introducing some degree of bias again). I know Renderman's denoise filter does a pretty good job and for gpu engines I think this is bread and butter. Anyway i guess this may be a way to go in general to get noise-free images more quickly. An of course, gpu speeds up all of it due to its architecture that is built specifically to tackle rendering tasks, unline general purpose cpu (that's why I think cpu rendering will die out eventually).

As for GPU option in Mantra, that would be certainly great... we'll see  

a few interesting videos on image filtering methods and importance sampling if anybody's interested: