Re: Finalgathering made less frustrating: mx_fgshooter
What does -thread 7 stands for ? don't use thread N°7 ? if you have 8 cores, is that it ? Le 02/04/2013 06:37, Jason S a écrit : More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI _*XSI.bat *_ @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* _*-thread 7*_ On 31/03/2013 7:12 AM, Tim Leydecker wrote: Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and it goes to the horizon resulting in only a few very bright spots in the scene that has to lit the whole room evenly. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker Sent: Friday, March 29, 2013 15:36 To: softimage@listproc.autodesk.com Subject: Finalgathering made less frustrating: mx_fgshooter Hi guys, there´s a lot to be desired about mental ray´s implementation and user friendliness. I don´t even want to start about
Re: Finalgathering made less frustrating: mx_fgshooter
Use 7 threads. The '-' just signifies it's an input argument to XSI... DAN On Tue, Apr 2, 2013 at 9:48 AM, olivier jeannel olivier.jean...@noos.frwrote: What does -thread 7 stands for ? don't use thread N°7 ? if you have 8 cores, is that it ? Le 02/04/2013 06:37, Jason S a écrit : More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI *XSI.bat * @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* *-thread 7* On 31/03/2013 7:12 AM, Tim Leydecker wrote: Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and it goes to the horizon resulting in only a few very bright spots in the scene that has to lit the whole room evenly. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.comsoftimage-boun...@listproc.autodesk.com] On
Re: Finalgathering made less frustrating: mx_fgshooter
The token could very well have been named threads in plural, because it's the amount of threads MR should use. And is NOT the same as setting the (entire) XSI process affinity to use only 7 threads (via TaskManager) which can give general computer responsiveness, but does'nt at-all change responsiveness within SI while rendering anything. Never found anything in the internet about that tiny little string. On 02/04/2013 2:48 AM, olivier jeannel wrote: What does -thread 7 stands for ? don't use thread N°7 ? if you have 8 cores, is that it ? Le 02/04/2013 06:37, Jason S a écrit : More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI _*XSI.bat *_ @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* _*-thread 7*_ On 31/03/2013 7:12 AM, Tim Leydecker wrote: Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and it goes to the horizon resulting in only a few very bright spots
Re: Finalgathering made less frustrating: mx_fgshooter
That's a little gem. Thanks Jason. DAN On Tue, Apr 2, 2013 at 7:37 AM, Jason S jasonsta...@gmail.com wrote: ** More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI *XSI.bat * @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* *-thread 7*
Re: Finalgathering made less frustrating: mx_fgshooter
Ok, Thank you :) Le 02/04/2013 08:52, Jason S a écrit : The token could very well have been named threads in plural, because it's the amount of threads MR should use. And is NOT the same as setting the (entire) XSI process affinity to use only 7 threads (via TaskManager) which can give general computer responsiveness, but does'nt at-all change responsiveness within SI while rendering anything. Never found anything in the internet about that tiny little string. On 02/04/2013 2:48 AM, olivier jeannel wrote: What does -thread 7 stands for ? don't use thread N°7 ? if you have 8 cores, is that it ? Le 02/04/2013 06:37, Jason S a écrit : More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI _*XSI.bat *_ @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* _*-thread 7*_ On 31/03/2013 7:12 AM, Tim Leydecker wrote: Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and
Re: Finalgathering made less frustrating: mx_fgshooter
My pleasure :) spread the word! On 02/04/2013 3:21 AM, olivier jeannel wrote: Ok, Thank you :) Le 02/04/2013 08:52, Jason S a écrit : The token could very well have been named threads in plural, because it's the amount of threads MR should use. And is NOT the same as setting the (entire) XSI process affinity to use only 7 threads (via TaskManager) which can give general computer responsiveness, but does'nt at-all change responsiveness within SI while rendering anything. Never found anything in the internet about that tiny little string. On 02/04/2013 2:48 AM, olivier jeannel wrote: What does -thread 7 stands for ? don't use thread N°7 ? if you have 8 cores, is that it ? Le 02/04/2013 06:37, Jason S a écrit : More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI _*XSI.bat *_ @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* _*-thread 7*_ On 31/03/2013 7:12 AM, Tim Leydecker wrote: Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of
Re: Finalgathering made less frustrating: mx_fgshooter
More about frustration alleviation with MR, for those that don't know : Given how SI can freeze-up to a crawl when a bunch of things are going in the RenderRegion, to the point of not even being able update it's own rendering tiles in the region (t'il it's done rendering) let alone changing settings or even just stopping the (damn) ;] render. .. if you append -thread 7 to your XSI.bat file, you can gain considerable UI responsivness at the expense of 1/8 less rendering performance well enough to change settings Wish I known this since multicores became common! Can't beleive for the life of me how such an (essential/basic/EASY) thing never made it to the UI _*XSI.bat *_ @echo off call C:\Program Files\Autodesk\Softimage 2013\Application\bin\setenv.bat start C:\Program Files\Autodesk\Softimage 2013\Application\bin\XSI.exe %* _*-thread 7*_ On 31/03/2013 7:12 AM, Tim Leydecker wrote: Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and it goes to the horizon resulting in only a few very bright spots in the scene that has to lit the whole room evenly. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker Sent: Friday, March 29, 2013 15:36 To: softimage@listproc.autodesk.com Subject: Finalgathering made less frustrating: mx_fgshooter Hi guys, there´s a lot to be desired about mental ray´s implementation and user friendliness. I don´t even want to start about having at least an in depth documentation including practical examples. Nevertheless, there´s yet another node that may come in
Re: Finalgathering made less frustrating: mx_fgshooter
Hi Sven, I´m also using the classroom scene as a base. Slight modifications to the windows to eliminate any terminator effects (like FG pushing through showing around the window framing, or also Arnold producing shading errors because the geo is singlesided and kept open there) basically, cleaning up the meshes and creating UVs. I don´t think this scene can become photorealistic, the models and proportions easily throw you off, even if only subconsiously. Nevertheless, I also try to get believable lighting into the scene. It´s hard. I´m using DisplayColorManagmentGamma Values 2.2. Beware of the physical sky and sun setup together with FinalGathering. In my personal opinion, it´s implementation it is at least misleading... The photographic exposure tonemapping makes it difficult to get a correct result, it´s very important to adjust the effect of burn_highlights based on the dialed in exposure until you get to match the FG preview and the final render. It´s best seen on the resulting physical sky color, the photographic exposure lensshader tonemaps the sky down too much. This offset is depending on the dialed in exposure, you can´t just crank up or down the exposure without counteradjusting the burn_highlights slider again. Please note, I´m not stupid enough to leave the photographic exposure gamma at 2.2, too. It´s set to 1. If I compare the skysun with various highdynamic range images on the environment and just final gathering without a sunlight, I also have to tone done finalgathering Primary Bounce Color and Secondary Bounce Color to 0.4545. Only then the FG calculation aligns perfectly with the final image then... Therefor I think the 1.0 default setting is wrong, the FG calculation is not affected by setting 2.2 display gamma settings but needs to be adjusted based on the Colormanagement settings. Not to mention that a first class *.hdr from Paul Debevec on the environment (for FG) forces me to throw away the photographic exposure lens shader to get to see anything useful. That alone is proof that the skysun setup should not be taken as willingly aligned and adjusted to artist´s needs... my personal opinion. -- In terms of classroom lighting: I cycled through Irradiance particles, Final Gathering and brute force methods. *Irradiance Particles gave me disappointing, large areas moving noise from frame to frame *FG can be stable if baked but is still quite difficult to get splotch free initially *FG re-calculated per frame using mip_fgshooter is better but not automatically free of flicker/pumping. *FG exact gave me crawling noise. I´m re-setting up the lighting today with a hdr environment and a mib_cied_dInfinite light and unified sampling. That gives me pretty reliable and controlable results, I would have liked to use the skysun setup but that crap doesn´t even tell you where North is... Cheers, tim On 29.03.2013 16:49, Sven Constable wrote: I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and it goes to the horizon resulting in only a few very bright spots in the scene that has to lit the whole room evenly. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker Sent: Friday, March 29, 2013 15:36 To: softimage@listproc.autodesk.com Subject: Finalgathering made less frustrating: mx_fgshooter Hi guys, there´s a lot to be desired about mental ray´s implementation and user friendliness. I don´t even want to start about having at least an in depth documentation including practical examples. Nevertheless, there´s yet another node that may come in handy but has probably slipped your radar: mip_fgshooter It is supposed to be used to add finalgather calculations from additional cameras to your current frame´s fgmap or your *.fgmap in general. I can´t express how frustrated I am about the implementation in Softimage. If you ever had hoped to having to figure out how to enter 4x4 matrixes and get the thing working yourself, brace for a lot of frustration. Or use this implementation. Thank you Denis Belyatsky! http://maxfoxlab.com/mx_fgshooter.html Hats off. If you push his implementation hard, you´ll notice the camera_shooter_cams will always have to point to the world origin to give realiable values for their resulting 4x4 matrixes entered into the render cam´s mip_fgshooter item list. Sofar, I haven´t been able to verify if that is a limitation of using their [cameraname].kineGlobal as the source for the 4x4 matrix or if that is due to the way the mip_fgshooter node
RE: Finalgathering made less frustrating: mx_fgshooter
I did tests with the fgshooter a few weeks ago on the classroom scene. And yes, its implemention is awful. I used the fgshooter addon too, its way easier then. Btw. I'm also still on the classroom scene and added light and camera animation, but I had no time to finish it yet. My goal is to make it as realistic as possible and bring mentalray onto its knees.:) Of course it has to be flickerfree, what is very hard when the sun is animated and it goes to the horizon resulting in only a few very bright spots in the scene that has to lit the whole room evenly. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker Sent: Friday, March 29, 2013 15:36 To: softimage@listproc.autodesk.com Subject: Finalgathering made less frustrating: mx_fgshooter Hi guys, there´s a lot to be desired about mental ray´s implementation and user friendliness. I don´t even want to start about having at least an in depth documentation including practical examples. Nevertheless, there´s yet another node that may come in handy but has probably slipped your radar: mip_fgshooter It is supposed to be used to add finalgather calculations from additional cameras to your current frame´s fgmap or your *.fgmap in general. I can´t express how frustrated I am about the implementation in Softimage. If you ever had hoped to having to figure out how to enter 4x4 matrixes and get the thing working yourself, brace for a lot of frustration. Or use this implementation. Thank you Denis Belyatsky! http://maxfoxlab.com/mx_fgshooter.html Hats off. If you push his implementation hard, you´ll notice the camera_shooter_cams will always have to point to the world origin to give realiable values for their resulting 4x4 matrixes entered into the render cam´s mip_fgshooter item list. Sofar, I haven´t been able to verify if that is a limitation of using their [cameraname].kineGlobal as the source for the 4x4 matrix or if that is due to the way the mip_fgshooter node interprets coordinates? In any case, Denis plugin is a great helper in actually making flickerfree FG available to the average user who may sure not be able to derive and properly set a 4x4 matrix himself. In terms of useability, I would have expected mip_fg_shooter to have a list entry field where you pick your cameras and that´s it. Like Lightlinking for selective light, even SRT coordinates would have been better but transform matrixes, really? That´s defeating the whole point of keeping it simple unless one could drag and drop a camera into the Rendertree and at least connect it directly there. Which you can´t... Cheers, tim
