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 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] 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








Reply via email to