Rendermap is a plugin if I'm not mistaken. It doesn't run through the same pipe as regular mental ray renders.
Matt From: [email protected] [mailto:[email protected]] On Behalf Of James De Colling Sent: Thursday, August 30, 2012 5:49 PM To: [email protected] Subject: Re: Small Annoying Things ok, normal render uses 100% cpu for FG point calculation, rendermap only uses 1 thread. (I tried the refinement passes option, to no avail) can anyone else confirm? Cheers, james, On Friday, August 31, 2012, James De Colling wrote: I will have a look at the refinement passed. In general rendermap is extremely slow compared to a normal render and as far as I know there is no progress or completion info for it either On Aug 31, 2012 8:13 AM, "Sven Constable" <[email protected]<mailto:[email protected]>> wrote: hm, MR does uses all cores and all CPUs for FG at least for standard rendering. Only the old photon mapping GI/caustics) is single threaded, if I rember correctly (the newer irridiance particles uses always all cores and cpus, even sattelite CPUs). In terms of FG only: In some cases ( or most) you can speed up the FG with using 'Refinment Passes' under the advanced options. Feels like It scales better on the cores than the default settings because it uses the MR tile order. It doesn't "hang" that much on certain FG tiles that happens sometimes with large FG maps. Maybe it depends on the scene but you should give it a try next time when you're having 8h of FG calculation. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of James De Colling Sent: Friday, August 31, 2012 0:29 To: [email protected]<mailto:[email protected]> Subject: Re: Small Annoying Things another one...and I do like that term, Mental Delay MR only uses 1 core to calculate FG points (in rendermap anyway) doing a 4k rendermap with FG just took me 8 hours...to calculate the FG..11 cores sitting idle On Friday, August 31, 2012, Luc-Eric Rousseau wrote: Users can't use the python that's installed with the Linux distribution. They need to use the version that's compatible with the pywin module compiled with MainWin by the development team and installed in the Softimage folder. It's not obvious to update pywin with new versions of python because no one else uses pywin on linux or gcc (obviously!) and therefore it's usually not just a recompile. we originally paid the creator of the package to port it for us On Thu, Aug 30, 2012 at 12:02 PM, Chris Chia <[email protected]<mailto:[email protected]>> wrote: > I don't understand. You can't get Linux Python to work? > > Chris > > On 30 Aug, 2012, at 11:50 PM, "Alan Fregtman" > <[email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>> > wrote: > > Not being able to use the system Python is a little annoying too. In Linux > we're stuck in Py2.5 because only the built-in Softimage Python works.
