不需要在一張一張的用Flickr網頁的上傳方式,
一個一個browse,
然後最多上傳六張實在是太鳥了,
趕快去用Firefox的Extension: Fotofox,
美美的介面,又可以加入一堆圖片,真是太爽了,
趕快去把他加入我的必裝firefox extension清單中。
安裝之後在navigation bar按照相機上傳的那個圖示
然後sidebar就會出現fotofox,
先選Login,然後Service選Flickr,按下Continue。
就會彈出一個視窗,
耐心點,他會連接到Flickr,
然後在按下 "OK I'LL ALLOW IT",
等網頁要求完成後再按下Finish這個按鈕。
然後就可以盡情的選擇圖片了,
最後在選上傳就可以了
Saturday, December 09, 2006
Maya在windows xp不能 playblast畫面大小超過1k
今天阿喬問到我這個問題,
雖然我會解決,
不過方法都是在自己腦子裡面,
想想好像不太好,
應該是要把這些東西訴諸紀錄,
這樣不認識我的人也可以找到解決辦法
其實方法很簡單,
就單純是XP的問題,
將"已相容模式執行這個程式"打勾 選擇Windows 2000
不要懷疑,這樣就可以了。
雖然我會解決,
不過方法都是在自己腦子裡面,
想想好像不太好,
應該是要把這些東西訴諸紀錄,
這樣不認識我的人也可以找到解決辦法
其實方法很簡單,
就單純是XP的問題,
- MAYA的捷徑上按右鍵選內容
- 選擇相容性這個tab
不要懷疑,這樣就可以了。
Friday, December 08, 2006
OcculisionMap render error with super frame
如果在OcclusionMap中使用[occmap camShape otf]這個function來取得Occlusion所產生的tex,
可是如果在super frame或是Dist+Render的情況下,且輸出的圖片長寬比不為1:1,
會將Screen算錯,就會變成有上下變形的情況,
看來OcclusionMap是廢掉了,雖然Pixar說他解決了了這Bug。
目前試過的解決辦法:
可是如果在super frame或是Dist+Render的情況下,且輸出的圖片長寬比不為1:1,
會將Screen算錯,就會變成有上下變形的情況,
看來OcclusionMap是廢掉了,雖然Pixar說他解決了了這Bug。
目前試過的解決辦法:
- 懷疑是occmap有問題,不使用occmap這個function,直接打rmantex/$JOBNAME.camShape.$F4.tex
- 失敗
- 於palette中加入一個名為frame的ribbox,修改ScreenWindow的值,使他不為-1 1 -0.75 0.75
- 失敗
- 將Occlusion的image type設成Final image,然後先算一次,取得occ image,然後將他手動轉成tex檔,在access設定為normal然後用Image File來讀圖。
- 成功,可是比較麻煩,要render兩次
- 綜合1和3的方法,在OcclusionMap中填入[txmake rmantex/$JOBNAME.camShape.otf.$F4.tex -smode black -tmode black -resize up-]
- 成功
txmake on local
Preflight commands can now be run remotely, based on compute location in RenderMan Globals.
In previous releases, even when selecting distributed rendering, preflight operations and resultant texture and shadow creation always took place on the local processor. In RAT 5.5.1, if the compute location is set to "remote", the standalone mtor preflight job will be run remotely. The resultant commands from the preflight expand (generally txmake commands) will run either locally or remotely depending upon an entry in the mtor.ini file.
In order for expanded commands within the preflight to run remotely you must define a service key entry for
"TxMakeSvc"
in the mtor.ini file. This is not set by default.
Leaving the TxMakeSvc defined as {} in the mtor.ini file (default configuration) will cause the txmake commands to be run on the local processor.
A suitable choice may be pixarRender (although a render slot will be consumed during txmake in this case) or simply define a custom service key and allocate appropriate servers in the alfred.schedule file.
In previous releases, even when selecting distributed rendering, preflight operations and resultant texture and shadow creation always took place on the local processor. In RAT 5.5.1, if the compute location is set to "remote", the standalone mtor preflight job will be run remotely. The resultant commands from the preflight expand (generally txmake commands) will run either locally or remotely depending upon an entry in the mtor.ini file.
In order for expanded commands within the preflight to run remotely you must define a service key entry for
"TxMakeSvc"
in the mtor.ini file. This is not set by default.
Leaving the TxMakeSvc defined as {} in the mtor.ini file (default configuration) will cause the txmake commands to be run on the local processor.
A suitable choice may be pixarRender (although a render slot will be consumed during txmake in this case) or simply define a custom service key and allocate appropriate servers in the alfred.schedule file.
Subscribe to:
Posts (Atom)