Thoughts on mantra
41640 75 15- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
Hello everyone
First a bit of background: I've been a 3dsmax user for around 14 years and have now began to learn Houdini over the past couple of weeks. I'm a generalist with focus on lighting/rendering and tool development, so Houdini was the next logical step for me.
With that out of the way I need to say that I'm blown away by what I can do with Mantra, especially shader building, access to everything everywhere and all that in a relatively straight forward way. I've used many different renderers over the years (though mostly vray these days) and I can safely say that mantra has been the most versatile yet.
(Brace yourselfs, now comes the big “BUT”) I know this has certainly been discussed endless times before and some users here will roll their eyes but I think it doesn't hurt to give a little feedback about mantra, even though or especially because I'm coming from a different DCC and business segment. All this versatility is currently little useful to me since I can barely render any production quality images with it. I have been trying to understand how mantra works, how to optimize it, made test renderings in comparison to other renderers I know and own but I just simply can't get its render times into a useful range for me (and if all goes to plan, the studio I'm working for). We use to render a lot in 4k lately, just recently an 11 minutes single camera exterior shot with hundreds of buildings and assets. Long story short: guessing from my tests, the same thing in mantra (instead of vray) would probably take 10 times as long. I definitely can not rule out errors on my side, I may have missed some crucial bit in my tests, but as far as I see it right now, mantra is out of the question as production renderer for us. So why am I writing this? I know there are 3rd party renderers, redshift and arnold foremost (whereas the latter is now owned by autodesk and thus not an option anymore). There will also be a vray for Houdini some time in the future, the version I tested is promising. But still, none of them is as versatile as mantra and I'd really love to use it, the integration and the features are just too good to ignore. The only thing that's holding me back (and others I spoke to) is the speed. I would gladly trade in half of vrays render speed for half of mantras capabilities, but we're quite far from that.
Don't get me wrong, I don't expect any responses promising that it will all change soon, I just wanted to give a bit of feedback and maybe that helps sidefx to plan future improvments. Please let me know if there is anything I should try to do in matra or clarify something I said above.
First a bit of background: I've been a 3dsmax user for around 14 years and have now began to learn Houdini over the past couple of weeks. I'm a generalist with focus on lighting/rendering and tool development, so Houdini was the next logical step for me.
With that out of the way I need to say that I'm blown away by what I can do with Mantra, especially shader building, access to everything everywhere and all that in a relatively straight forward way. I've used many different renderers over the years (though mostly vray these days) and I can safely say that mantra has been the most versatile yet.
(Brace yourselfs, now comes the big “BUT”) I know this has certainly been discussed endless times before and some users here will roll their eyes but I think it doesn't hurt to give a little feedback about mantra, even though or especially because I'm coming from a different DCC and business segment. All this versatility is currently little useful to me since I can barely render any production quality images with it. I have been trying to understand how mantra works, how to optimize it, made test renderings in comparison to other renderers I know and own but I just simply can't get its render times into a useful range for me (and if all goes to plan, the studio I'm working for). We use to render a lot in 4k lately, just recently an 11 minutes single camera exterior shot with hundreds of buildings and assets. Long story short: guessing from my tests, the same thing in mantra (instead of vray) would probably take 10 times as long. I definitely can not rule out errors on my side, I may have missed some crucial bit in my tests, but as far as I see it right now, mantra is out of the question as production renderer for us. So why am I writing this? I know there are 3rd party renderers, redshift and arnold foremost (whereas the latter is now owned by autodesk and thus not an option anymore). There will also be a vray for Houdini some time in the future, the version I tested is promising. But still, none of them is as versatile as mantra and I'd really love to use it, the integration and the features are just too good to ignore. The only thing that's holding me back (and others I spoke to) is the speed. I would gladly trade in half of vrays render speed for half of mantras capabilities, but we're quite far from that.
Don't get me wrong, I don't expect any responses promising that it will all change soon, I just wanted to give a bit of feedback and maybe that helps sidefx to plan future improvments. Please let me know if there is anything I should try to do in matra or clarify something I said above.
- neil_math_comp
- Member
- 1743 posts
- Joined: March 2012
- Offline
If there's anything you can submit to support that's unreasonably slow to render, that'd be appreciated. In the scenes I've seen, there's often something simple that's the cause of the slow rendering, sometimes easy to avoid or fix. However, it's often (understandably) very difficult for studios to package up or simplify these scenes and send them to us, so we don't receive as many as I'd like, unfortunately.
As an example that's come up a few times, people often test performance in Render View with Preview on, which is inherently a bit slower than having Preview off, but can also sometimes hit a catastrophic performance spiral with high resolutions or many image planes with the default settings, where it eventually spends almost all of its time sending and re-sending to Houdini pixel data that will never be displayed, instead of actually rendering. Setting Update Time in the Render View toolbar to 10 instead of the default 1 usually fixes that, (or turning off Preview), but this is just one example. There are many different things that can cause large performance slowdowns, and it's very difficult to know what's going wrong without a scene.
As an example that's come up a few times, people often test performance in Render View with Preview on, which is inherently a bit slower than having Preview off, but can also sometimes hit a catastrophic performance spiral with high resolutions or many image planes with the default settings, where it eventually spends almost all of its time sending and re-sending to Houdini pixel data that will never be displayed, instead of actually rendering. Setting Update Time in the Render View toolbar to 10 instead of the default 1 usually fixes that, (or turning off Preview), but this is just one example. There are many different things that can cause large performance slowdowns, and it's very difficult to know what's going wrong without a scene.
Edited by neil_math_comp - Oct. 12, 2017 09:29:20
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
Thanks for the reply ndickson! I currently cannot offer any production scenes as the one I described but I can certainly prepare one of my test scenes. They are really simple to eliminate any unknown variables and generally just test one specific aspect. I'll also export the scene to max and render it in vray, for comparison. It may take a while though, I'll post everything here once I got it done.
For those tests I always render with “preview” off, I also do not include any AOVs (to minimize variables). I also usually render a couple of frames directly to disc to have a good average without any redraw slowdowns. Btw, rendering to disk AND being able to watch the progress in mplay would be most welcome. I can only see if something in the current frame went wrong after the image is completed (bonus points for Redshift here )
For those tests I always render with “preview” off, I also do not include any AOVs (to minimize variables). I also usually render a couple of frames directly to disc to have a good average without any redraw slowdowns. Btw, rendering to disk AND being able to watch the progress in mplay would be most welcome. I can only see if something in the current frame went wrong after the image is completed (bonus points for Redshift here )
- Olaf Finkbeiner
- Member
- 323 posts
- Joined: Jan. 2015
- Offline
Hi there,
i used 3dsMax since DOS and switched to Houdini a few years ago.
Yes Mantra is very versatile and i love it.
The H16 Mantra/Material update was huge!
I am looking forward to H16.5 and also hope for “speed” improvements.
I heard rumors and one thing i hope for is a nicer noise distribution.
After learning a lot i am now able to to get ok speeds. Only with pure indirect interieur light i am not happy.
And maybe i would say Mantra is 2-3times slower.
BUT, if you dont just do classic product viz Mantra will allow you to render stuff that you just can not render at all in other renderers. Eg.: I made a very realistic fully procedural wood material. Or i use point clouds for dirt masks.
Or look at the ocean shader material.
Furthermore i love the possibilty to output any custom AOVs. This can save you so much time in post production that even a ten times slower Beauty pass might be ok. This opened my eyes: https://cmivfx.com/houdini-passes-master-class [cmivfx.com] He creates 50! usefull AOVs for this project.
regards
Olaf
i used 3dsMax since DOS and switched to Houdini a few years ago.
Yes Mantra is very versatile and i love it.
The H16 Mantra/Material update was huge!
I am looking forward to H16.5 and also hope for “speed” improvements.
I heard rumors and one thing i hope for is a nicer noise distribution.
After learning a lot i am now able to to get ok speeds. Only with pure indirect interieur light i am not happy.
And maybe i would say Mantra is 2-3times slower.
BUT, if you dont just do classic product viz Mantra will allow you to render stuff that you just can not render at all in other renderers. Eg.: I made a very realistic fully procedural wood material. Or i use point clouds for dirt masks.
Or look at the ocean shader material.
Furthermore i love the possibilty to output any custom AOVs. This can save you so much time in post production that even a ten times slower Beauty pass might be ok. This opened my eyes: https://cmivfx.com/houdini-passes-master-class [cmivfx.com] He creates 50! usefull AOVs for this project.
regards
Olaf
- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
@Olaf Finkbeiner: Yes, that's what I mean, there are ways to some of these things in other renderers (including vray) but it's nowhere as easy as in houdini. No need to write custom plugins or scripted workarounds.
Same scene brought to max and vray did yield some varying results. I'm do not know how SSS is calculated in the disney principled shader, so I rendered several versions - with the VRayALSurfaceMtl and the VRaySSS2 material. ALSurface is raytraced by default, I made sure the SSS2 one is set to pure raytraced too (for fairness). Vray is around 2 to 3 times faster, with a more even noise distribution. The SSS2 variant with 1m42s looks closest to the mantra rendering to me, but this is obviously subjective.
It's not the difference in render times I wanted to show, but I thought it is fair to share it anyways. Let me know if you think there is something I could try in mantra that could help.
I know of course that there are plenty of things that can have an influence on render times. The render time difference is also not as much as I thought, so I wouldn't count this scene as a good example.
Ok, attachments are a bit chaotic here. In order:
- Houdini mantra 4:35
- vray alsurface directional 2:24
- vray alsurface diffusion 2:04
- the shadow fireflies in mantra
- vray FastSSS2 1:42
I would gladly trade in half of vrays render speed for half of mantras capabilities, but we're quite far from that.I may actually have to correct myself here. I just rendered an SSS scene where I was completely sure the difference is huge. Turned out, it's “kind of” not as much as I thought (at least if everything is purely raytraced). The scene does not have any GI turned on, just one area light. Mantra took about 4.5 minutes on my machine and has some colored fireflies here and there (which are actually getting way worse in the shadow areas, see below). I tried to optimize the settings best I could, with lowest possible render times as a goal.
Same scene brought to max and vray did yield some varying results. I'm do not know how SSS is calculated in the disney principled shader, so I rendered several versions - with the VRayALSurfaceMtl and the VRaySSS2 material. ALSurface is raytraced by default, I made sure the SSS2 one is set to pure raytraced too (for fairness). Vray is around 2 to 3 times faster, with a more even noise distribution. The SSS2 variant with 1m42s looks closest to the mantra rendering to me, but this is obviously subjective.
It's not the difference in render times I wanted to show, but I thought it is fair to share it anyways. Let me know if you think there is something I could try in mantra that could help.
I know of course that there are plenty of things that can have an influence on render times. The render time difference is also not as much as I thought, so I wouldn't count this scene as a good example.
Ok, attachments are a bit chaotic here. In order:
- Houdini mantra 4:35
- vray alsurface directional 2:24
- vray alsurface diffusion 2:04
- the shadow fireflies in mantra
- vray FastSSS2 1:42
Edited by racoonart - Oct. 12, 2017 11:29:23
- amm
- Member
- 98 posts
- Joined: Aug. 2014
- Offline
Perhaps to give a chance to Physical sss, it's part of Mantra Classic shader. Something like single scatter with enabled spectral gradient, should give a well known BSSRDF look. Still, it will need higher quality settings, but it is usable, without fireflies and such.
Subsurface shader in H 16 relies on indirect rays which seems to be over optimistic for Mantra capabilities. Also it seems to be almost impossible to get a rich spectral effect, nicely noticeable with V-Ray subsurface, unless using two or three shaders on top of each other, which is then close to impossible to get clean.
Unfortunately, IMO H 16 introduced several step-backs, compared to earlier versions, like that unhappy sss, Mat network horrible to manage, insisting on crippled (un)principled shader. Future looked brighter in times of H 14.
Subsurface shader in H 16 relies on indirect rays which seems to be over optimistic for Mantra capabilities. Also it seems to be almost impossible to get a rich spectral effect, nicely noticeable with V-Ray subsurface, unless using two or three shaders on top of each other, which is then close to impossible to get clean.
Unfortunately, IMO H 16 introduced several step-backs, compared to earlier versions, like that unhappy sss, Mat network horrible to manage, insisting on crippled (un)principled shader. Future looked brighter in times of H 14.
- martinkindl83
- Member
- 262 posts
- Joined: Nov. 2014
- Offline
Its always a big battle about render options.
We started with Mantra as its very convenient for many users, especially the build-in shaders, where you dont have to understand what they are doing and dont need to tweak them. Once you start tweaking things, you realize that its very time consuming and messy. Thus i (and im saying I, not we!) stopped using the prebuild shaders. From beginning (3years ago) i was noticing the speed difference compared to Arnold in XSI. So i was only one in company using Arnold and every one else were using Mantra. As time went, more and more people realized that even though the Arnold is pain to use, is not as user friendly to use (this is only the Houdini Arnold specific case), the speed advantage is huge. I always wanted to have discussion at the start of the project about what will be the best rendered for given project. But when i look back 1year on all project we did, we stopped having that discussion and use Arnold 95% of the time.
Im not saying its the best renderer, dont get me wrong. It just works for us. I know my good friends in another studio are using Mantra and cant complain. For me i have lot of to complain when im forced to use Mantra (especially the speed), but on the other hand, some stuff is easier to use in Mantra.
At the end its the user preference.
We started with Mantra as its very convenient for many users, especially the build-in shaders, where you dont have to understand what they are doing and dont need to tweak them. Once you start tweaking things, you realize that its very time consuming and messy. Thus i (and im saying I, not we!) stopped using the prebuild shaders. From beginning (3years ago) i was noticing the speed difference compared to Arnold in XSI. So i was only one in company using Arnold and every one else were using Mantra. As time went, more and more people realized that even though the Arnold is pain to use, is not as user friendly to use (this is only the Houdini Arnold specific case), the speed advantage is huge. I always wanted to have discussion at the start of the project about what will be the best rendered for given project. But when i look back 1year on all project we did, we stopped having that discussion and use Arnold 95% of the time.
Im not saying its the best renderer, dont get me wrong. It just works for us. I know my good friends in another studio are using Mantra and cant complain. For me i have lot of to complain when im forced to use Mantra (especially the speed), but on the other hand, some stuff is easier to use in Mantra.
At the end its the user preference.
- Olaf Finkbeiner
- Member
- 323 posts
- Joined: Jan. 2015
- Offline
- anon_user_40689665
- Member
- 648 posts
- Joined: July 2005
- Offline
yep lets see those scenes…
Two other thing to consider:
- Reliability. Even though its slower per-frame, Mantra will get you to final sooner than a faster but glitchier renderer as you're not wasting hours of overnight farm time. In my experience so far Mantra with a completely native setup has been 100% reliable.
- Simplicity. Going native means your scenes should be faster to render; no re-caching to 3rd-party formats, no working-around shader limitations, no working-around unsupported Houdini features, no troubleshooting of unusual renderer-specific problems, no troubleshooting of broken dependencies, no additional layer of licensing BS.
Also: abandoning Mantra and using 3rd-party renderers invites the risk of Mantra becoming like COPs or the OGL-ROP: “nobody” uses Houdini for compositing or previz so they're not wasting resources on improving it. This makes Houdini less value for smaller generalist crews, pushing it back into its FX-for-big-studios niche, where there has been serious competition (like the Max+Fume+TP combo last decade).
Better to make good use of your AUP if you're on one, send support very specific examples of what's slowing you down on production. Be persistent.
Two other thing to consider:
- Reliability. Even though its slower per-frame, Mantra will get you to final sooner than a faster but glitchier renderer as you're not wasting hours of overnight farm time. In my experience so far Mantra with a completely native setup has been 100% reliable.
- Simplicity. Going native means your scenes should be faster to render; no re-caching to 3rd-party formats, no working-around shader limitations, no working-around unsupported Houdini features, no troubleshooting of unusual renderer-specific problems, no troubleshooting of broken dependencies, no additional layer of licensing BS.
Also: abandoning Mantra and using 3rd-party renderers invites the risk of Mantra becoming like COPs or the OGL-ROP: “nobody” uses Houdini for compositing or previz so they're not wasting resources on improving it. This makes Houdini less value for smaller generalist crews, pushing it back into its FX-for-big-studios niche, where there has been serious competition (like the Max+Fume+TP combo last decade).
Better to make good use of your AUP if you're on one, send support very specific examples of what's slowing you down on production. Be persistent.
- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
Ok, I have attached the scene, in case someone wants to play with it. I only included the cache for 1 frame, so you need to render at frame 72.
Btw, I invite everyone to contribute to this thread with example scenes.
@amm, Olaf Finkbeiner: I tried the SSS in the classic shader, it's not faster however. I made a test with slightly lowered noise threshold to be closer to Vrays result, see below. I did not try the deprecated mode yet. Will do that next. I started with H16, so I have no idea how it was before (edit) I can't seem to find a spectral gradient setting anywhere, I also have difficulties matching the look with the PhysicalSSS. Maybe you can have a try, amm?
@martinkindl83: That kind of matches my experience. We are a small company but do a lot of rendering. If we can somehow speed up that process, we do it, even if that means a bit more manual preparation on the artist side. The shot I mentioned above took a bit over 2 weeks on about 20 machines, 10-20 minutes each frame. Even a 50% render time drop would have made delivery difficult (or way more costly, buying more machines).
@cpb: Not wanting to abandon Mantra is exactly the reason why I started this thread in the first place I do not want to use a 3rd party renderer if possible. I'd like Mantra to be that “uber” renderer it is feature wise … it just needs a bit more speed. You are mentioning Simplicity and Reliability: I didn't include my Redshift results here because of these very reasons. I think Redshift is reliable, but less well integrated and you need GPUs in your render farm (which we do not have). The render times however are blasting away pretty much everything. It took just 15s to get a clean image in that particular case - but as I said, it's not my intention to compare apples with bananas.
Btw, I invite everyone to contribute to this thread with example scenes.
@amm, Olaf Finkbeiner: I tried the SSS in the classic shader, it's not faster however. I made a test with slightly lowered noise threshold to be closer to Vrays result, see below. I did not try the deprecated mode yet. Will do that next. I started with H16, so I have no idea how it was before (edit) I can't seem to find a spectral gradient setting anywhere, I also have difficulties matching the look with the PhysicalSSS. Maybe you can have a try, amm?
@martinkindl83: That kind of matches my experience. We are a small company but do a lot of rendering. If we can somehow speed up that process, we do it, even if that means a bit more manual preparation on the artist side. The shot I mentioned above took a bit over 2 weeks on about 20 machines, 10-20 minutes each frame. Even a 50% render time drop would have made delivery difficult (or way more costly, buying more machines).
@cpb: Not wanting to abandon Mantra is exactly the reason why I started this thread in the first place I do not want to use a 3rd party renderer if possible. I'd like Mantra to be that “uber” renderer it is feature wise … it just needs a bit more speed. You are mentioning Simplicity and Reliability: I didn't include my Redshift results here because of these very reasons. I think Redshift is reliable, but less well integrated and you need GPUs in your render farm (which we do not have). The render times however are blasting away pretty much everything. It took just 15s to get a clean image in that particular case - but as I said, it's not my intention to compare apples with bananas.
Edited by racoonart - Oct. 13, 2017 04:30:14
- martinkindl83
- Member
- 262 posts
- Joined: Nov. 2014
- Offline
- symek
- Member
- 1390 posts
- Joined: July 2005
- Offline
Thanks for a scene. Could you also provide CPU spec for your timings?
SSS is particularly hard for comparisons though. SSS shaders are convoluted and if algorithm are not stated explicitly by developers, they are hard to compare visually. It's hard to say from a single frame, that particular implementation behaves comparably well as other, albeit robustness and physical correctness may cost serious difference in timings and pays off only in hard areas. I'm not implying Mantra's SSS is high quality btw, or that SSS scenes are not important - quite opposite - SSS speed and quality somewhat indicated matureness of a renderer. I'm saying that scene like this doesn't serve well as a benchmark of a renderer itself.
SSS is particularly hard for comparisons though. SSS shaders are convoluted and if algorithm are not stated explicitly by developers, they are hard to compare visually. It's hard to say from a single frame, that particular implementation behaves comparably well as other, albeit robustness and physical correctness may cost serious difference in timings and pays off only in hard areas. I'm not implying Mantra's SSS is high quality btw, or that SSS scenes are not important - quite opposite - SSS speed and quality somewhat indicated matureness of a renderer. I'm saying that scene like this doesn't serve well as a benchmark of a renderer itself.
- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
I'm currently testing on an i7-5820K @3.3Ghz (6 cores, 12 threads).
Yes, I know this is a rather questionable test (as said above) since it's so dependent on the specific implementations. I would definitely not use it as a benchmark or base any scientific conclusions on that. However, I did upload it nonetheless since in the end, users judge based on “result” and actual production value. It doesn't matter which implementation it is, as long as it looks convincing, is reliable and renders fast I tried to keep it at least somewhat fair by just comparing pure raytraced methods, no caches or interpolations (even though that would make a difference in actual production).
Yes, I know this is a rather questionable test (as said above) since it's so dependent on the specific implementations. I would definitely not use it as a benchmark or base any scientific conclusions on that. However, I did upload it nonetheless since in the end, users judge based on “result” and actual production value. It doesn't matter which implementation it is, as long as it looks convincing, is reliable and renders fast I tried to keep it at least somewhat fair by just comparing pure raytraced methods, no caches or interpolations (even though that would make a difference in actual production).
- amm
- Member
- 98 posts
- Joined: Aug. 2014
- Offline
racoonart
@amm, Olaf Finkbeiner: I tried the SSS in the classic shader, it's not faster however. I made a test with slightly lowered noise threshold to be closer to Vrays result, see below. I did not try the deprecated mode yet.
Well I meant exactly the ‘deprecated’ mode - that is, Physical SSS. Otherwise, yeah you'll get exactly the same H 16 ‘PBR’ subsurface thing.
- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
- david_maas
- Member
- 59 posts
- Joined: Feb. 2008
- Offline
Over at discord, Alexander Weide has been doing an interesting extorsion of the h16 hair shader to get really fast, noiseless sss. Worth a look:
“ the Hair Transmission works perfectly in H16… the result looks stunning in my eyes… compared to the internal principled shader sss which looks like total crap. its rendering fast like hell even on 2 million polygons”
“this is the result of the principled shader sss change. :wink: btw 254 packed primitivs each one has 1 million polygons, rendertime was quite short with this shader, about 30 minutes and selfmade bokeh at rendertime”
“ the Hair Transmission works perfectly in H16… the result looks stunning in my eyes… compared to the internal principled shader sss which looks like total crap. its rendering fast like hell even on 2 million polygons”
“this is the result of the principled shader sss change. :wink: btw 254 packed primitivs each one has 1 million polygons, rendertime was quite short with this shader, about 30 minutes and selfmade bokeh at rendertime”
- Ludvík Koutný
- Member
- 33 posts
- Joined: Aug. 2013
- Offline
I have to second Racoonart's opinion here. After brief experience of Houdini, while I did see all the flexibility Mantra has to offer, all of this flexibility is overshadowed by how incredibly slow renderer it is.
What I find confusing here is that it appears as if people assumed there is some bug which makes Mantra slow in some specific cases/scenes, but that is not the case at all. Mantra has inferior performance to pretty much any production renderer out there in vast majority of scenes. And not by a little, but by far.
It's pretty much impossible to render any kind of interior scene or scene with significant amount of purely indirectly lit surfaces in a reasonable time. No matter how flexible it is, it doesn't really help you if you can't afford the resources to get your shot done.
But what's significantly more concerning is, that while pure path tracers (which Mantra not even is) generally fail at largely indirectly lit scenes, they at least excel in scenes that have plenty direct illumination, like Arnold renderer for example. Mantra, on the other hand, tends to fail, performance-wise, even in these scenes, which are trivial when it comes to light transport complexity.
My first suggestion would be to implement Intel's Embree raytracing kernels, which should provide good baseline for raytracing performance. The idea was already brought up few years ago, but dismissed by one of the developers with argument, that Embree is not mature/flexible enough. Well, these day, Embree has gone a long way, and is used in quite a few widespread mainstream renderers.
Once Embree is in, next step would probably be to re-evaluate if basic mechanisms like multiple importance sampling and light solvers are indeed working correctly and optimally, because right now, it doesn't seem that is the case.
What I find confusing here is that it appears as if people assumed there is some bug which makes Mantra slow in some specific cases/scenes, but that is not the case at all. Mantra has inferior performance to pretty much any production renderer out there in vast majority of scenes. And not by a little, but by far.
It's pretty much impossible to render any kind of interior scene or scene with significant amount of purely indirectly lit surfaces in a reasonable time. No matter how flexible it is, it doesn't really help you if you can't afford the resources to get your shot done.
But what's significantly more concerning is, that while pure path tracers (which Mantra not even is) generally fail at largely indirectly lit scenes, they at least excel in scenes that have plenty direct illumination, like Arnold renderer for example. Mantra, on the other hand, tends to fail, performance-wise, even in these scenes, which are trivial when it comes to light transport complexity.
My first suggestion would be to implement Intel's Embree raytracing kernels, which should provide good baseline for raytracing performance. The idea was already brought up few years ago, but dismissed by one of the developers with argument, that Embree is not mature/flexible enough. Well, these day, Embree has gone a long way, and is used in quite a few widespread mainstream renderers.
Once Embree is in, next step would probably be to re-evaluate if basic mechanisms like multiple importance sampling and light solvers are indeed working correctly and optimally, because right now, it doesn't seem that is the case.
Edited by Ludvík Koutný - Oct. 14, 2017 10:56:26
- racoonart
- Member
- 39 posts
- Joined: Feb. 2017
- Offline
@david_maas: Sounds very interesting! Would love to know what he did exactly
Ok, next scene. This one was provided by Ludvík Koutný and is available here: https://corona-renderer.com/forum/index.php?topic=4354.0 [corona-renderer.com] . The scene may be used for testing purposes but may not be sold or used as a portfolio piece (which I think shouldn't be necessary to mention). You can find my exported version in Houdini below.
A typical interior, a rather easy one to render. Some notes about it:
- I have setup the portals in a way I think makes sense. I'm not sure what the official workflow is meant to be but I found it rather cumbersome (compared to other rendering engines).
- I'm using a GiLight for secondary bounces and (obviously) Pathtracing for the first bounce. I did the same setup in Vray, Brute force + Lightcache (mostly defaults).
- I've used a style sheet for the material override in houdini and specified a viewport selection (for some reason the scene blow up when I just used * as a path value, maybe something related to the portals?)
- I have tried to get both images as clean as possible in as little time as possible. In vray it was pretty much just open scene and press render, in houdini I did quite a bit of tweaking. It's still not as clean as the vray render. I also have a lot of issues with the photon map since the photon samples get interpolated through geometry (which is prevented in vray by retracing those close-proximity areas).
- I also get light leaks in the upper left corner, the little white pixels are primary rays, this should not be happening. I decreased the raytracing bias to 0.0001 which helped (it was a white line before), but didn't want to set it to complete zero since I don't know how it would affect other raytrace operations.
So, long story short, pictures in order (rendered on an i7-5820K @3.3Ghz (6 cores, 12 threads)):
- Vray 5m28s
- Mantra 18m20s
- Mantra photon map issues and noisy areas
Please let me know if and how I can optimize that scene and get better quality especially in the GiLight.
Ok, next scene. This one was provided by Ludvík Koutný and is available here: https://corona-renderer.com/forum/index.php?topic=4354.0 [corona-renderer.com] . The scene may be used for testing purposes but may not be sold or used as a portfolio piece (which I think shouldn't be necessary to mention). You can find my exported version in Houdini below.
A typical interior, a rather easy one to render. Some notes about it:
- I have setup the portals in a way I think makes sense. I'm not sure what the official workflow is meant to be but I found it rather cumbersome (compared to other rendering engines).
- I'm using a GiLight for secondary bounces and (obviously) Pathtracing for the first bounce. I did the same setup in Vray, Brute force + Lightcache (mostly defaults).
- I've used a style sheet for the material override in houdini and specified a viewport selection (for some reason the scene blow up when I just used * as a path value, maybe something related to the portals?)
- I have tried to get both images as clean as possible in as little time as possible. In vray it was pretty much just open scene and press render, in houdini I did quite a bit of tweaking. It's still not as clean as the vray render. I also have a lot of issues with the photon map since the photon samples get interpolated through geometry (which is prevented in vray by retracing those close-proximity areas).
- I also get light leaks in the upper left corner, the little white pixels are primary rays, this should not be happening. I decreased the raytracing bias to 0.0001 which helped (it was a white line before), but didn't want to set it to complete zero since I don't know how it would affect other raytrace operations.
So, long story short, pictures in order (rendered on an i7-5820K @3.3Ghz (6 cores, 12 threads)):
- Vray 5m28s
- Mantra 18m20s
- Mantra photon map issues and noisy areas
Please let me know if and how I can optimize that scene and get better quality especially in the GiLight.
Edited by racoonart - Oct. 13, 2017 14:20:47
- RobotHeadArt
- Member
- 41 posts
- Joined: Dec. 2016
- Offline
- Konstantin Magnus
- Member
- 682 posts
- Joined: Sept. 2013
- Offline
Regarding the interior scene: It´s not in scale (usually 1 unit = 1 meter). Also you can avoid light leaks by giving walls and ceiling some thickness.
https://procegen.konstantinmagnus.de/ [procegen.konstantinmagnus.de]
-
- Quick Links