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.fr>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 Display>ColorManagment>Gamma 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 sky&sun 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 sky&sun 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_d>Infinite light > and unified sampling. That gives me pretty reliable and controlable > results, I would have > liked to use the sky&sun 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<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 > > > > > > >
