R: fgmap limitation & black frames

40 views
Skip to first unread message

Max

unread,
Jul 21, 2011, 8:09:28 AM7/21/11
to soft...@listproc.autodesk.com

Hello, 


i have the same problem, noticed the weird CPU usage from Final gather, it doesnt use all my 12 cores, then when it reaches the end of the FG passes (usually 3) it drop down and it is inconsistent.

I guess it is a problem of implementation or Mental Ray, i've never be able to find the cause and kinda dropped the hopes for a fix.

For the point 2 problem, i guess those are NaN black squares, have few experience with them but sometimes they pop out of nowhere due to some problem in render calculation.


I'll keep an eye on this thread because i'm interested too into solving those issues.


Max


----Messaggio originale----
Da: benjamincl...@gmail.com
Data: 21-lug-2011 11.17
A: <soft...@listproc.autodesk.com>
Ogg: fgmap limitation & black frames



Hi everyone,

I have two rendering questions questions if I may (2012 sp1, win 7 64b):
  1. I'm preparing final gather maps for sequences by appending fg info into a .fgmap file every 25 frames... everything works fine except only the first frame of a sequence gets 100% of my cpu (at creation of the .fgmap). Every frame after (appending to .fgmap already created) is limited to 25% of my processor - resulting in a 4x render time increase!
    I've tried rendering framesets from xsi and xsibatch, I've also tried rendering just one image at a time - hoping the fact I re-initiated it would throw my cpu back up to 100% (which it didn't).

  2. Any idea why I would have black unrendered squares randomly pollute about 10% of rendered images? Some shots use FG, others GI, others both, some are just occlusion passes - it doesn't seem to discriminate (unfortunately!).
Thanks in advance for any advice,

Ben

--
Benjamin Clifford Davis

3D artist - Senior Modeler
Senior 3D Generalist

www.bcdavis.info


office:   +33 9 50 04 76 15
mobile: +33 6 88 48 54 50

6 bis avenue des Iles
74000 Annecy
FRANCE



Konstantinos Stamatelos

unread,
Jul 21, 2011, 10:34:59 AM7/21/11
to Max, soft...@listproc.autodesk.com
Hi guys,

Both the issues you describe below about the fgmap performance drop and the random black tiles are known to us and are part of our active bug database. There is an ongoing investigation by our development team and Mental Images.

The problem with the dropped tiles is a bit tricky as it seems to be machine specific. Not all machines exhibit this problem and so it’s difficult to provide concrete reproduction proof to Mental Ray.

Unfortunately the only workaround at the moment is to re-render any frames that exhibit black tiles, as it is unlikely that it will occur twice for the same frame.

Thanks,

Konstantinos Stamatelos
QA Rendering and General Testing Specialist
Autodesk Media and Entertainment

Autodesk, Inc.
10 Duke
Montreal, QC H3C 2L7
514.954.7123


[Description: Adsk_logo_4_sig_v03_crop.gif]




From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Max
Sent: Thursday, July 21, 2011 8:09 AM
To: soft...@listproc.autodesk.com
Subject: R: fgmap limitation & black frames


Hello,



i have the same problem, noticed the weird CPU usage from Final gather, it doesnt use all my 12 cores, then when it reaches the end of the FG passes (usually 3) it drop down and it is inconsistent.

I guess it is a problem of implementation or Mental Ray, i've never be able to find the cause and kinda dropped the hopes for a fix.

For the point 2 problem, i guess those are NaN black squares, have few experience with them but sometimes they pop out of nowhere due to some problem in render calculation.



I'll keep an eye on this thread because i'm interested too into solving those issues.



Max


----Messaggio originale----
Da: benjamincl...@gmail.com
Data: 21-lug-2011 11.17
A: <soft...@listproc.autodesk.com>
Ogg: fgmap limitation & black frames




Controllo ortografico<http://posta58a.mailbeta.libero.it/cp/ps/Main/WindLayout?d=libero.it&u=radius.radius&t=43d65d75d6290936>

|

Aggiungi firma [http://mailbeta-static.libero.it/cp/images/default/en/uikit/img_transparent.gif] <http://posta58a.mailbeta.libero.it/cp/ps/Main/WindLayout?d=libero.it&u=radius.radius&t=43d65d75d6290936>






Invia messaggio <http://posta58a.mailbeta.libero.it/cp/ps/Main/WindLayout?d=libero.it&u=radius.radius&t=43d65d75d6290936>

Salvata<http://posta58a.mailbeta.libero.it/cp/ps/Main/WindLayout?d=libero.it&u=radius.radius&t=43d65d75d6290936>

Annulla<http://posta58a.mailbeta.libero.it/cp/ps/Main/WindLayout?d=libero.it&u=radius.radius&t=43d65d75d6290936>






[http://mailbeta-static.libero.it/cp/images/default/en/uikit/img_transparent.gif]


Hi everyone,

I have two rendering questions questions if I may (2012 sp1, win 7 64b):

1. I'm preparing final gather maps for sequences by appending fg info into a .fgmap file every 25 frames... everything works fine except only the first frame of a sequence gets 100% of my cpu (at creation of the .fgmap). Every frame after (appending to .fgmap already created) is limited to 25% of my processor - resulting in a 4x render time increase!
I've tried rendering framesets from xsi and xsibatch, I've also tried rendering just one image at a time - hoping the fact I re-initiated it would throw my cpu back up to 100% (which it didn't).
2. Any idea why I would have black unrendered squares randomly pollute about 10% of rendered images? Some shots use FG, others GI, others both, some are just occlusion passes - it doesn't seem to discriminate (unfortunately!).
Thanks in advance for any advice,

Ben

--
Benjamin Clifford Davis

3D artist - Senior Modeler
Senior 3D Generalist

www.bcdavis.info<http://www.bcdavis.info/>
image001.gif

Ben Davis

unread,
Jul 21, 2011, 10:58:16 AM7/21/11
to soft...@listproc.autodesk.com
Thanks for the quick answers! I'm glad you guys at Autodesk are at it.

Meanwhile we found something that seemed to help the black tiles issue: it appears that the more cores you have rendering the same image, the more chances of getting black tiles... Since 9 of our render machines are biproc hexacores (12 physical cores), we're only allowing 6 max per task - but still use all 12 by having 2 render tasks run side by side.

Kind of the same workaround for the fgmaps: without limiting the affinity of cores to anyone we put 2 projects on each machine - seems to level out the drop by stuffing the cpu with more work to do :)

Can't wait for SP2! héhé!

Ben

--
Benjamin Clifford Davis

3D artist - Senior Modeler
Senior 3D Generalist

www.bcdavis.info



Reply all
Reply to author
Forward
0 new messages