Renderman

Given that, you might try increasing the amount of time that alfserver waits before escalating to SIGKILL. One second is a long time for a process to be unresponsive. Try small increments, for example, in alfserver.ini change this line: SetPref timerAlfserverSignalEscalation 3 Also, the log indicates that you are running the server as root, which would be ok if you were causing the actually-launched apps to run as a different user. I think you’ve got “AlfProcessOwnerConfig login root” set in your alfserver.ini ? There is a chance that the “login” mode is adding an extra layer of complexity to this issue. ...

大約三週之前，開發 Nuke 的 The Foundry ，由 CEO, Bill Collis, 偕同技術人員 Matt Plec 與兩位美麗的華裔女士來台，參與了 SIGGRAPH 2008 Taipei Chapter 的活動，會後立即趕來太極，面對太極的幾位 compositors，給了一個更加深入一點的 talk + demonstration。 Matte 就 Nuke 與 Ocula 做了不少的 demo，像是 3D scene/model/camera importing by FBX、multi-channel manipulation、customized gizmo、stereoscopic vector viewing by Ocula、stereoscopic offset、stereoscopic filein handling…其中我最感興趣的，是 Nuke 的可程式化能力。 Nuke 5 發佈的特色之一是對 Python scripting 的支援。根據我 k 了文件後的了解，幾乎所有在 Nuke 裏頭的操作，都可以使用 Python 來做到，於是乎，有很大的空間可以就「自動化」與「整合其它軟體或服務」做延伸上的開發。我對於這一點感到非常的興奮。相對於 Apple Shake 限制多多的 shake macros 與我們一直無緣拿到手的 Shake SDK，Nuke 對 programmer 實在友善太多了。 我立即寫了個 python script，做了點設定上的調整，在 Nuke 上頭多新增了一個 Digimax 的 menu，然後裏頭有個 Submit To Render Farm 的功能。目的是透過它來產生一個 alfscript 來，然後呼叫 alfred 把 nuke rendering 給送進 render farm。 ...

The following is from Dan Maas: I just query the camera attributes using the normal Maya MEL commands. For example “getAttr cam.worldInverseMatrix” gives you the camera transform and “getAttr cam.focalLength” the focal length. You can call these from the code that generates your procedural. Maya->RenderMan conversions are as follows: 1. invert the 3rd column of the worldInverseMatrix to convert from right-handed to left-handed coordinates (i.e. multiply m[2] m[6] m[10] and m[14] by -1) 2. RenderMan’s “perspective” camera FOV = rad_to_deg(2_atan((xres/yres)_12.7/cam.focalLength))

如果因為一些原因，你需要自行在 RIB 裏頭產生一段 camera 相關的參數來（像是使用 prman 的 multi-camera 這個 13.5 才有的新功能），那這篇文章就是在提示你，怎麼搞懂 RIB 裏頭，camera 會用到的 transformation, perspective 參數乃至於 screenwindow。 Transformation 取出 camera 的 worldInverseMatrix 這個屬性出來（用 mel 或 python 都可），它是一個 matrix。然後因為 RenderMan 是使用左手座標系統，而 Maya 是使用右手座標系統，所以你還得把這個 matrix 的第三行（直行橫列）的值變為相反數，亦即把第三行的值（m[2] m[6] m[10] and m[14]）乘上 -1。 Perspective RenderMan’s “perspective” camera FOV = rad_to_deg(2*atan((xres/yres)*12.7/cam.focalLength)) ScreenWindow 這部分，可以參考我的好同事 Mao 所寫的一篇 blog 。 感謝 Dan Maas 的解說 :)

Bernard Edlington 在他的 blog 上發起了一個 RenderMan community of Japan 的活動，主要就 RenderMan 技術上的討論，目的在日本推廣 RenderMan 這個東西，同時匯集身在日本，使用 RenderMan 的人。同時，他還預計在今年的 SIGGRAPH 2008 期間，在 LA 進行第二階段的活動，讓旅外的日本人也有機會參與到。 我只能說，他相當的用心吶… 有趣的是，他好像是一位外國人，但是他的 blog 有好多日文呀 :o

故事是這樣的。 因為遇到了個小問題，於是跑去 RenderMan 官方的支援網站 問，然後官方一位「常態性回覆官員」出現，先問了我是用 RenderMan Studio (RMS) 還是 MTOR 7.0，然後說我的問題可能沒好的解決方案喔。結果官方的另一位「感覺起來，比較資深的官員」跟著出現，他澄清了一下，我的那個小問題，不管是 RMS 或是 MTOR 都可以用同樣的小撇步解決，因為關鍵程式 it (Image Tool） ，在兩者之下，運行起來是一模一樣的。 下頭是這一位官員的回覆： Sure. Its part of it, not RMS. It gets run from “it” for any render that is send to, well, it. You set the post render script in the “it” settings that ian described. (Note to self, never name a software product “it”) ...

這應該是我使用 Pixar’s RenderMan 以來，看過最落落長的一個 rendering job 了。粗略地算了一下，有 300 個左右的 task，且根據原作者（發表在 Pixar’s RenderMan 官方討論版裏頭）的說詞，有一半是 ptfilter，另一半是 brickmap，我的天…是什麼情況會用到這麼多的 ptfiter，難道是有 100 多顆彈珠散落一地嗎? 最近無聊時，在想一件事。就是呢，為平麼有這麼多的事情都可以被表示成一個樹狀結構（tree）或是圖（graph）呢? 就拿 rendering 這件事來說，一個 RenderMan 的一個 frame，可以被拆成很多個 task，然後每個 task 之間的關係，就組成了像左圖那樣的一個樹狀結構。 然後呢，因為 rendering 真的很費時，至少就 animation 來說是這樣的。（遊戲就當做特例吧，如果一個遊戲的 rendering 要很久的話，會有人想玩嗎?）爭取時間的方法之一就是平行運算（parallel computing）。如果以 task 為最小的運算單元來看，那如何做到同時可以有很多個 task 同時運算，就是重點了。就樹狀結構來看，屬同一層級（sibling）的 task 就可以同時運算，彼此互不相干。 所以呢，這應該就是以樹狀結構來表示一個 job 的好處之一呢? 說來說去，我只是覺得這個 job 的 task 實在太多了，有點噁心，希望我們家的 lighter 不會產生這種 job 來 XD

Glass scene rendered in POV-Ray, demonstrating radiosity, photons, focal blur, and other photorealistic capabilities 當 Opensource 裏頭，有悠久歷史，且常常是學習電腦圖學（Computer Graphics）中的算圖（Rendering）領域的學子，會去拿來當作一個練習平台的 POV-Ray (@Wikipedia )，遇上了工業上赫赫有名的 RenderMan 標準時，就誕生了 POV-Man 這個計畫。 就個人來說，會忍不住想給 POV-Ray 灌上有點神祕，學術上比較高貴的感覺，原因無它，就因為它讓我覺得很遙遠，無從著手，而且除了看到使用它算出來的圖的品質不錯以外，完全不曉得可以拿它來幹麻。 右邊這一張圖，是使用 POV-Ray 算出來的圖，它有 raytracing 特有的反射（reflection）、折射（refraction）和聚焦（caustics，是這樣翻的嗎?）。這張圖同時還算出來景深（Depth of Field）、軟軟的影子（soft shadow，應該不是這樣翻的吧）。 在 1999 年，在 POV-Ray 的 newsgroup 上有這麼一段： ...