星期三, 8月 31, 2011

批次輸出 cache

(
fn outputCache obj folderPath recordStart recordEnd sampleRate mode:1 =
(
try( deletemodifier obj obj.modifiers[#Point_Cache_Binding] ) catch()
try( deletemodifier obj obj.modifiers[#Point_Cache] ) catch()
local pcMod = undefined
if mode == 1 then pcMod = copy(pointCache()) else pcMod = copy(PointCacheWSM())
if pcMod == undefined do ( print "unknow mode" ; return false )
addmodifier obj pcMod
pcMod.fileCount = 0
pcMod.recordStart = recordStart
pcMod.recordEnd = recordEnd
pcMod.sampleRate = sampleRate
pcMod.filename = (folderPath +"\\"+obj.name+".xml")
if getCommandPanelTaskMode() != #modify do setCommandPanelTaskMode #modify
modpanel.setCurrentObject obj.modifiers[1]
classof obj
cacheOps.RecordCache obj.modifiers[1]
true
)
-- 用法 --
selObjs = selection as array
for obj in selObjs do
(
outputCache obj "c:\\Temp\\Out" 0.0 161.0 1 mode:2
)
)
最近寫的小型工具,有須要請自己取用。
又很久沒寫blog了,都在玩ssf4啊…

星期二, 7月 12, 2011

Classof 原來可以這樣用…

今天看到Bobo講了才知道,原來 classof 還有這等妙用。

我之前寫某個工具時剛好也為了 modifier 的狀態不更新而煩腦,當時是用其他的方法解決了,等等再拿這個方式去試試看可以不可以用這個方式解。

 

This is because when you put the code in a function, the code becomes the body and is run as a multiline expression within a single undo record. During this, scene updates, viewport redraws etc. are suspended until the whole body has finished executing. As result, the modifier stack is not updated until the function has finished executing, and the modifier is in the wrong state.

In contrast, when you run the code within the global scope, each line is executed individually and causes the modifier stack to be updated too.

You can force a modifier stack update by adding the line 'classof theShape' right after the addModifier() call. When you ask for the class of an object, MAXScript checks to see if the stack needs updating because it needs to figure out what the class is ON TOP of the stack. (You could have a shape turned into a mesh turned into EPoly turned into EPatch and back to EMesh within the stack, so without updating the whole stack Max cannot know what the result would be). So classof() is a nice workaround in almost all cases where a modifier was added but has not been updated yet.

You could also call 'select theShape', but that would force a scene update, too, which can be slower than just updating the stack.

 

->出處<-


大意是,把code包起來之後,code 就會以一個 undo 的單位下去執行,沒包之前則是一行就會可以做一次undo。
而在一個undo單位下執行中,場景更新,視窗重繪等等的會全部暫停更新。而 modifier stack也是等到執行完再一次更新 ,
這時要是去找modifier stack拿資訊就會拿到未更新狀態的資訊。

而 classof 這個函式會強迫 modifier stack 更新狀態,因為有可以該物體是mesh後轉成editpoy後又轉成 edit patch最後再轉回mesh,為了查得該個物體的 class,所以一定要先更 modifier stack,不更新就查不到。 

還有另一個選擇是用 select ,不過 select 會有場景更新,相對而言的就比較慢。

 

星期六, 5月 14, 2011

i9000 再次刷rom

唉,好死不死就手賤去摔到手機。
平常也摔了不少次,連我兒都幫我摔過,沒想到就這一次摔出了毛病…

送修原廠就代表重刷rom…
就又代表著要備份…重灌軟體。

不過最煩的還是重刷rom。只好再爬一下文,找回怎麼解鎖三鍵,怎麼用odin,刷哪個rom好…,不小心就又看到提升 gps 準度的好物

弄了半天,真的難免會覺得…
到底是我在用智慧性手機還是它在用我…?

星期三, 4月 27, 2011

struct, struct, rollot

最近試著 mxs 中 的 strcut 裡再包一個 struct。
想要達成像是…

frontWheel = car.wheel()

這樣子虛華的語法…

當然,很快的就找到方法了。不過雖然在直譯時會過,但是struct裡的變數卻怎麼也吃不到,失敗…

再接再厲的…
我又想把 rollout也包在 struct 裡,當然,之是很快的就發現這樣做是沒問題了,而且可以用

car.showControlWindow()

這樣虛華的語法來建立視窗。
只是再一次的…在某些部份會掛掉,在特地的某些點裡會指名要求明確的指出要用的是那個struct裡的那個變數…

好像又白走了一些路…(嘆)

===================================================================

結果後來發現其實有人早就這樣子寫了,這個寫法有個好處就是可以把程式裡的所要用到的東西都共享,然後只有用到一個全區變數。還蠻好用的喔~

星期四, 3月 17, 2011

filters struct

寫script時常常會須要用到判斷這東西是不是一個某某物件或是某某類別
通常就是自己用 classof或是iskindof
不過其實max有寫了一個 filters 的結構體,寫的完整許多,可以直接拿來用。

用法大致上是這樣

b1 = box()
select b1
filters.Is_EditMesh()

就可以了
要判斷的物體是要選取的而不是用傳參數的,這點跟我自己的用法有點不同。不過這種用法執行速度好像比較快…

其他的還有像

filters.Is_EditSpline()
filters.Is_EditPatch()
filters.Is_EditPoly()
filters.is_MeshSelect()
filters.is_SplineSelect()
filters.is_PatchSelect()
filters.is_PolySelect()

等等的,有用到的人可以去
C:\Program Files\Autodesk\3ds Max 2011\stdplugs\stdscripts\filterfunctions.ms
查看原始碼~

星期三, 3月 16, 2011

FBX 在script中可以用的指令,備忘一下

help裡給的指令實在太舊了點。
查了一下資料。怕也後忘記,在這裡備忘一下

可以用
FBXImporterGetParam “FBXProperties”
或是
FBXExporterGetParam “FBXProperties”
得到全部的 fbx 指令

一列出來…有這麼多呢…
PATH: Import|PlugInGrp|PlugInUIWidth    ( TYPE: Integer ) ( VALUE: 600 )
PATH: Import|PlugInGrp|PlugInUIHeight    ( TYPE: Integer ) ( VALUE: 600 )
PATH: Import|PlugInGrp|PlugInUIXpos    ( TYPE: Integer ) ( VALUE: 660 )
PATH: Import|PlugInGrp|PlugInUIYpos    ( TYPE: Integer ) ( VALUE: 285 )
PATH: Import|PlugInGrp|UILIndex    ( TYPE: Enum )  ( VALUE: ENU  )  (POSSIBLE VALUES: < ENU > < DEU > < FRA > < JPN > < KOR > < CHS >  )
PATH: Import|IncludeGrp|MergeMode    ( TYPE: Enum )  ( VALUE: Add to scene  )  (POSSIBLE VALUES: < Add and Update scene elements > < Update scene elements > < Add to scene >  )
PATH: Import|IncludeGrp|Geometry|SmoothingGroups    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|IncludeGrp|Animation    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|ExtraGrp|Take    ( TYPE: Enum )  ( VALUE: IN_cut07_TDMS_001  )  (POSSIBLE VALUES: < No animation > < IN_cut07_TDMS_001 >  )
PATH: Import|IncludeGrp|Animation|ExtraGrp|TimeLine    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|IncludeGrp|Animation|ExtraGrp|BakeAnimationLayers    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|ExtraGrp|Markers    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|IncludeGrp|Animation|ExtraGrp|PointCache    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|Deformation    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|Deformation|Skins    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|Deformation|Shape    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|CurveFilter    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyCstKeyRed    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyCstKeyRed|CurveFilterCstKeyRedTPrec    ( TYPE: Number ) ( VALUE: 0.000090 )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyCstKeyRed|CurveFilterCstKeyRedRPrec    ( TYPE: Number ) ( VALUE: 0.009000 )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyCstKeyRed|CurveFilterCstKeyRedSPrec    ( TYPE: Number ) ( VALUE: 0.004000 )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyCstKeyRed|CurveFilterCstKeyRedOPrec    ( TYPE: Number ) ( VALUE: 0.009000 )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyCstKeyRed|AutoTangentsOnly    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyKeyReduce    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyKeyReduce|CurveFilterKeyReducePrec    ( TYPE: Number ) ( VALUE: 1.000000 )
PATH: Import|IncludeGrp|Animation|CurveFilter|CurveFilterApplyKeyReduce|CurveFilterApplyKeySync    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|IncludeGrp|Animation|SamplingPanel|SamplingRateSelector    ( TYPE: Enum )  ( VALUE: Scene  )  (POSSIBLE VALUES: < Scene > < File > < Custom >  )
PATH: Import|IncludeGrp|Animation|SamplingPanel|CurveFilterSamplingRate    ( TYPE: Number ) ( VALUE: 30.000000 )
PATH: Import|IncludeGrp|Animation|Bone|BoneWidthHeightLock    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|Animation|Bone|BoneAsDummy    ( TYPE: Enum )  ( VALUE: Leave as bones  )  (POSSIBLE VALUES: < Leave as bones > < Convert as dummy >  )
PATH: Import|IncludeGrp|Animation|Bone|Max4BoneWidth    ( TYPE: Number ) ( VALUE: 1.000000 )
PATH: Import|IncludeGrp|Animation|Bone|Max4BoneHeight    ( TYPE: Number ) ( VALUE: 1.000000 )
PATH: Import|IncludeGrp|Animation|Bone|Max4BoneTaper    ( TYPE: Number ) ( VALUE: 0.900000 )
PATH: Import|IncludeGrp|CameraGrp|Camera    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|LightGrp|Light    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|IncludeGrp|LightGrp|Environment    ( TYPE: Bool ) ( VALUE: false )
PATH: Import|AdvOptGrp|UnitsGrp|DynamicScaleConversion    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|UnitsGrp|UnitsSelector    ( TYPE: Enum )  ( VALUE: Centimeters  )  (POSSIBLE VALUES: < Millimeters > < Centimeters > < Decimeters > < Meters > < Kilometers > < Inches > < Feet > < Yards > < Miles >  )
PATH: Import|AdvOptGrp|AxisConvGrp|AxisConversion    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|AxisConvGrp|ZUProtation_max    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|AxisConvGrp|UpAxisMax    ( TYPE: Number ) ( VALUE: 1.000000 )
PATH: Import|AdvOptGrp|UI|ShowWarningsManager    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|UI|GenerateLogData    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Obj|ReferenceNode    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|ReferenceNode    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Texture    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Material    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Animation    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Mesh    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Light    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Camera    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|AmbientLight    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Rescaling    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Filter    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|FileFormat|Max_3ds|Smoothgroup    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|Dxf|WeldVertices    ( TYPE: Bool ) ( VALUE: true )
PATH: Import|AdvOptGrp|Dxf|ObjectDerivation    ( TYPE: Enum )  ( VALUE: By layer  )  (POSSIBLE VALUES: < By layer > < By entity > < By block >  )
PATH: Import|AdvOptGrp|Dxf|ReferenceNode    ( TYPE: Bool ) ( VALUE: true

指定值時要給fullpath,像是
FBXImporterSetParam “Import|IncludeGrp|Animation|Markers” true





星期五, 2月 25, 2011

黑客與畫家 - 好文共享

嗯…我想我沒辦法講的像 Paul Graham 這麼精闢,不過我有感受程式實作中對於"美"的要求絕不亞於畫家對對於畫面上的經營,不然我不會這麼喜歡程式這東西。

我…也要再去讀計算機科學嗎…(還真想…)

以下為譯文,出自 好好学习,天天向上
直接用google翻繁中,請見諒。

=======================================================
本文是Paul Graham 寫的一篇關於黑客與畫家共同之處的文章,深入探討了黑客工作的藝術性與創造性。雖然大部分的程序員都覺得藝術是一件很遙遠的事情,但對於那些願意仔細打磨代碼追求精益求精的優秀黑客來說,在創造的過程中總是能感受到藝術的真實存在(儘管可能只是 隱約感受到,而且羞於把自己和藝術聯繫起來)。藝術之所以會讓人覺得高高在上遠離生活,是因為大部分人都是在衣著光鮮地談論著藝術,而不知道什麼是創造。要成為一個創造者,你所要做的不是誇誇其談,而是投入全部熱情去不斷實踐。

原文 | 譯文地址

黑客與畫家

我讀完計算機本科以後,去藝術學校學習繪畫。許多人感到奇怪,喜歡計算機的人也會喜歡美術嗎?他們大概認為編程序和畫畫是兩種完全不同的工作,編程需要冷靜,精密,和正確的方法,而畫畫是表達某種狂熱的情感。

這種印像是不對的,編程和畫畫有很多共同之處,實際上,在我認識的不同類型的人中間,畫家和黑客是最相似的。

畫家和黑客的相似之處在於:他們都是創造者,就好像作曲家,建築師,以及作家一樣。黑客和畫家類似,他們的目的是創造某種美好的事物。儘管在創造的過程中,也許會發現新技術,但他們的根本目的並不是研究技術。

我從來都不喜歡”計算機科學”這個詞,因為這種東西根本就不存在。
這門學科的內容,不過是由於歷史原因偶然湊合到一起的大雜燴,就好像南斯拉夫國的形成一樣。
一頭是數學家們,他們擺弄計算機是為了得到國防部的資金贊助,中間部分,一夥人在研究彷彿是計算機自然史之類的東西--比如網絡上數據流算法的行為特徵等等。在另一個極端上,是黑客們,他們編寫有趣的軟件。對他們來說,計算機是表達的工具,如同水泥之於建築師,顏料之於畫家。這三種人湊在一塊的群體,就好像是數學家,物理學家和建築師被分到一個專業裡。

有時候黑客們幹的事被稱為”軟件工程”,這個詞也是一種誤會。比起建築師來,軟件設計師離工程師的距離更遠。建築師和工程師的分界並不十分精確,但卻是實實在在存在的。其分界在於做什麼和如何做:建築師決定做什麼,工程師考慮如何做出來。

這兩件事情也不能分得太開,如果你不懂得如何做,那麼你設計的時候就會陷入難局。 但是編程當然不是僅僅決定如何實現某種特性那麼簡單,在最好的情況下,編程實際上就是設計軟件的特性--往往最好的設計方式就是實現它。

說不定哪一天,”計算機科學”會分裂成幾個專業,就好像南斯拉夫最終分裂成幾個國家那樣。 這也許是件好事。 尤其是這意味著我所擅長的編程,會變成獨立的專業。

這些不同類型的工作綁到一個專業裡,當然有利於行政管理,但是卻會引起智力上的困惑。 這也是我不喜歡這個名詞的另一個原因。 處於中間部分的那伙人所干的,和經驗科學差不多,但是另外兩頭的人,數學家和黑客,可不太像是在幹真正的科學。

數學家好像並不為這個問題發愁,他們就像數學系的同行一樣,很高興地做著理論研究,不久就忘了辦公大樓的牌子寫的是”計算機科學系”。 但是對黑客們來說,這個牌子就很成問題。 既然他們幹的事被稱作科學,他們就會感到好歹要像那麼回事,於是大學和研究所的黑客們覺得應該寫論文,而不是寫優美的程序。 但是不幸得很, 後者才是他們真正應該干的。

論文充其量不過是一個手續。 黑客寫出很棒的程序,然後再做一篇論文,論文表示軟件上的成績。 但是兩者之間的不協調引起了問題:好的軟件比起糟糕的軟件來,更加不適合做論文的題材。

好的軟件不適合作論文的題材。 首先,論文要有獨創性的,寫過博士論文的都知道,要想保證你開墾的那片地是處女地,就等於說是你劃出一片別人都不想要的地來。 第二,論文必須言之有物。 糟糕的軟件使論文材料充足,你有很多事實可以描述你是如何克服那些困難的。 糟糕的假設總是會產生大量問題。 大部分AI 研究就是好例子。 比如,你假定,以抽象概念為參量的邏輯表達式列表可以用來表示知識,那你要論證的內容可就多了。 就像Ricky Ricardo說的,Lucy,這下可夠你解釋了。

創造美好事物的過程,常常是對已有事物的細微調整,或者是把已有概念用新方式組合起來。 這種事情,恐怕不太好做研究論文吧。

那麼為什麼大學和研究所還要用論文來衡量黑客呢? 同樣的, 為什麼要用標準化考試來衡量學術才能呢? 為什麼要用代碼行數來衡量程序員的工作量呢? 這些考試的好處是容易實施,而且有一點效果, 因此才會引誘我們繼續採用這些措施。

真正的黑客能夠寫出優雅的代碼, 但是識別這種黑客的方法,真的很不容易找到。 要有好的嗅覺才可能識別出真正優秀的設計。 是否真的有這種嗅覺,和是否自信有這種嗅覺,這兩者之間沒什麼關聯,即使有,也是負面的。

真正的考驗是時間。 經過時間的考驗,好的東西會發展壯大,壞的東西會丟棄。 不幸的是,需要的時間往往太長, 以至超過人的壽命。 Samuel Johnson說,需要一百年的時間,才能形成一個作家的真正聲譽。 你得等到這個作家有影響的朋友都死了,他的追隨者也都死了才行。

我想黑客不得不接受名聲上的不確定性,這一點上, 他們和其他創造者沒什麼不同。 實際上比較起來還要幸運一些。 在編程領域,一時的流行風氣雖然也有影響,但沒有繪畫領域那麼大。

還有比別人的誤解更糟的事情。 更糟的危險是你可能自己誤解自己。 你通常在相關領域尋找靈感。 如果你在計算機系,很自然地會以為,編程的本質就是實現計算機理論。 我讀本科的時候有一種令我很不舒服的感覺,我覺得自己應當多學一點計算機理論,可是期末考試完了不到三個禮拜,我就把那些東西全忘光了。 這讓我覺得自己不夠盡責。

現在我認識到我那時的想法都是錯誤的。 黑客對計算機理論的了解程度,只要達到畫家對顏料化學所了解的程度就夠了。 你應當知道怎樣計算時間和空間複雜度,知道圖靈機模型。 也許應當知道狀態機,至少知道這個概念,如果要寫語法解析或者正則表達式庫的時候會用得到。 畫家對顏料的學問上,要記的東西比這還要多一些呢。

對我來說,靈感的源泉不是來自於那些掛著計算機招牌的地方,而是那些聚集著創造者的地方。 我從繪畫方面得到的靈感比我從計算機理論上得到的,要多得多。

打個比方。 我上學的時候,學生在上機之前,要把整個程序先用紙筆寫出來。 可是我覺得這不是我寫程序的方式。 我喜歡坐在計算機前面寫程序,根本不用紙筆。 我並不先在紙上寫出程序並檢驗其正確性,我喜歡先敲一段代碼,當然好多毛病,然後慢慢敲打成型。 我受到的教育告訴我,調試應當是檢查輸入錯誤的最後一關,而按照我的方式,程序基本上就是調試出來的。

好長一段時間我都感到很沮喪,念小學的時候,我捉鉛筆的方式和老師教的不一樣,那時我也感到同此刻一樣的沮喪。 如果我那會知道別的創造者-比如畫家和建築師-的做法的話,我就早該知道這種方法的名字,那就是:打草稿。 我可以告訴你,他們在大學時教我的方法是錯的。 你應當是一邊寫程序一邊來確定程序的走向, 這和畫家, 作家以及建築師的做法完全一樣。

這裡蘊涵著軟件設計的真義, 認識到這一點, 就意味著程序語言應當首先要具有延展性。 語言要有助於在編程中思考, 而不是僅僅表達思考的結果。 它應該象鉛筆, 而不是像鋼筆。 如果程序員真的像大學裡教的那樣寫程序, 那麼靜態類型語言就是不錯的選擇。 但是我所知道的黑客都不是那樣子編程序的。 我們需要這樣一種語言, 我們用它來隨意塗抹。 而使用靜態類型語言編程序的感覺, 就好像手放在膝蓋上, 小心翼翼握著茶杯, 正襟危坐著和一個嚴肅的老太太談話。

談論靜態類型, 以及創造者這種話題, 我們除去了另外一個困擾的科學的問題: 數學嫉妒。 科學界的每個人暗地裡都認為數學家比自己聰明。 我想數學家們自己大概也這麼認為。 反正科學家們總是把自己的作品弄得像數學論文一樣。 這對物理學倒還沒什麼大害, 但是你要是在自然科學上走得越遠, 就越發現這個問題的嚴重性。

印上一整頁的公式, 看上去很讓人敬畏的樣子, 用上希臘字母就更加不得了。 這種傾向可能誘惑你去研究那些可以公式化的問題, 結果是忽略了真正重要的東西。

如果黑客認同創作者的身份, 像是畫家和作家一樣, 他們就不會受此誘惑。 作家和畫家才不理會數學呢, 根本就是不相干的事情。 我認為, 黑客也應當這樣看。

如果大學和研究所不讓黑客做自己想做的事情, 他們還可以去公司, 可惜, 公司和大學的做法是一丘之貉。 大學和研究所要求黑客當科學家, 而公司要求黑客當工程師。

我也是最近才發現這問題的。 Yahoo買了Viaweb之後, 他們問我的意向, 我一向就不喜歡商業公司, 我就說我還是想編程序。 進了Yahoo以後, 我發現在他們那裡, 編程序的意思就是代碼實現, 和設計沒關係。 程序員就是代碼工人, 他們把產品經理的願望, 以代碼形式記錄下來。

看起來這是大公司的一貫的做法。 這樣做的目的是減低工作的偏差。 只有少數程序員真正懂得設計軟件, 而且這些有才能的人很不容易一下子識別出來。 所以與其把軟件的未來寄託在少數聰明人身上, 不如把軟件設計讓一個委員會來作, 程序員只管編碼實現。

如果你想賺錢, 那麼記住我的話, 因為我講的, 正是小公司取勝的機會。 大公司採取保險的做法, 意圖規避風險。 但是試圖限制這種工作效果上的震蕩的時候, 固然避免了最壞的可能,但也失去了最好的。 這對大公司當然不是問題, 大公司取勝的原因不是因為發明了偉大的產品, 而是因為犯的錯誤比其他大公司少而已。

如果你有辦法和一個大公司競爭某種產品, 這個公司的產品是產品經理們設計的, 那麼, 他們永遠趕不上你。 不過這樣的機會很不容易找到。 你很難和大公司捲入軟件競爭, 就好比你很難和對手在城堡裡徒手搏鬥一樣。 寫一個比微軟的word還要好的字處理器是可能的, 但是在操作系統這個微軟獨占的堡壘裡, 他們對你根本就不屑一顧。

軟件競爭只能在全新的市場中展開, 因為在那裡還沒有誰建立起防禦工事。 你有可能採取大膽的策略, 集合那些既做設計又做編碼的人, 來贏得競爭。 微軟最初就是這樣做的, 蘋果,HP也莫不如此。 我想任何成功的創業公司都是走的這條路。

所以, 創造偉大軟件的一個辦法就是創業開公司。 不過這裡面還有兩個問題。 第一, 開公司以後, 除了編程序, 你需要做好多其他事情。 在Viaweb的時候, 我真的希望自己能擠出四分之一的時間編程就好了。 實際上我四分之三的時間都是在做很討厭甚至很麻煩的事情。 對此我深有體會, 有一次當我開完董事會去補牙, 坐在診所的椅子上, 我覺得簡直抵得上度假了。

還有另一個問題。 寫有趣的軟件, 和寫賺錢的軟件, 經常是沒多少共同之處。 設計語言是很有趣的工作, 微軟的第一個產品就是。 但是現在沒人會花錢買語言。 要想賺錢就得寫那種很麻煩的, 沒人會免費幹的軟件。

所有的創造者都會面臨這個問題。 價格是供求關係決定的, 對有趣軟件的需求總是比較少,而解決一般用戶的平凡問題的需求, 總是多一些。 在高速公路邊上演出, 觀眾一定少, 在廟會搭個台子演出, 觀眾一定多。 寫長篇小說的收入, 比不上寫廣告詞的收入, 雖然那些廣告最後的歸宿是垃圾箱。 設計一種語言的回報一定不多, 而搞定某些公司的老掉牙的數據庫和web server的連接問題, 回報會豐厚得多。

我認為這個難題的答案, 是創造者們應當找一個養家糊口的”日常工作”。 這個名詞最初是慣於晚上演出的音樂家們使用的。 它的意思是: 你做一個工作是為了賺錢, 另一個工作是因為你喜歡。

幾乎所有的創造者在他們職業生涯的早期, 都有日常工作。 其中最為人所知的就是畫家和作家。 如果能賺錢的日常工作剛好是你所喜愛的工作, 那你就太幸運了。 音樂家就經常在唱片店工作。 正在用某種語言或者操作系統的黑客, 也應當找個相近的系統管理或維護的工作。 [1]

黑客應當找個日常工作糊口, 業餘時間做自己喜愛的程序。 我的這個說法並不是獨出心裁。 所有的開源社區的黑客都是這樣做的。 我要說的是, 開源社區的模型也許是正確的模型, 因為這種模型被其他創造者分別獨立地驗證過。

一般的雇主都不太願意僱員參與開源項目, 這讓我有一點驚奇。 在Viaweb則相反, 我們不願意僱傭沒有做過開源項目的人。 面試程序員的時候, 我們考慮的一個首要問題就是, 他們業餘時間寫什麼軟件。 你要不是真的熱愛這個工作, 就不可能幹的出色。 如果你熱愛編程, 就必然會有自己熱愛的業餘項目。 [2]

黑客是創造者, 不太像是科學家。 黑客尋找靈感的地方, 不應當是科學領域, 而是其他創造者工作的領域。 那麼, 我們從繪畫上, 能夠得到什麼啟示呢?

第一件可以從繪畫領域學習的, 或者說可以驗證的, 就是怎樣學習編程。 繪畫都是在實踐中學會的, 編程亦然。 大部分黑客都不是因為念大學計算機課才走上編程之路的。 他們13歲年紀就開始學著寫程序。 即使是上了大學計算機課, 你真正學會編程, 大多也是通過自己實際寫程序。 [3]

畫家通常會留下一系列作品, 你可以從中觀察到他們在實踐中學習的過程。 如果你按年代順序觀察一個畫家的作品, 你會發現後一個作品在前一個作品基礎上的提高。 如果一幅畫中的某樣東西特別出色, 你多半會在更早的作品中發現其發展成熟的軌跡。

我認為大多數創造者都是這樣工作的。 作家和建築設計師也不例外。 對於黑客而言, 我覺得這樣的做法大概比較好: 從一個大概的草稿開始起步, 不斷嘗試採納新的想法, 做修訂版,而不是連續幾年埋頭做一個題目。

這種工作模式是區別黑客和科學家的另一個顯著標誌。 科學家並不通過乾活來學習科學, 他們通過做實驗和解題來學習科學。 科學家總是從完美的東西開始, 也就是說他們重複前人已經做過的工作, 最後達到某種高度, 才開始做自己創造性的工作。 而黑客呢, 一開始就是做創造性的工作–當然這時候作品還不成樣子。 黑客從創造開始, 最終達到完美。 而科學家從完美開始, 最終達到創造。

創造者學習的另一種方法是觀摩傑作。 對畫家來說, 美術館是技巧的寶庫。 幾百年來, 美術館都是畫家學習和借鑒大師作品的地方, 它成為傳統教育方式的一個部分。 觀摩傑作強迫畫家仔細觀察那幅畫是如何畫成的。

作家也是如此。 本傑明-富蘭克林曾經總結Addison和Steel的散文的特點, 並加以模仿。 Raymond Chandler也是這樣學寫偵探小說的。

同樣, 黑客也是通過看優秀的程序來學習編程–不僅看它的外在表現, 而且要看源碼。 開源軟件有一個少人提及的優點就是: 你很容易從中學習編程。 我學編程的時候, 不得不依賴書裡的例子。 其中有一大堆代碼是屬於Unix的, 但Unix也不開源。 大部分人是讀John Lions的書裡的源代碼, 而這些內容是不合法的。 這本寫於1977年的書, 直到1996年都還被禁止出版。

繪畫的過程就是不斷改進的過程, 這是值得我們學習的另一個地方。 繪畫通常從草圖開始,逐漸地添上細節, 但又不僅僅是添上細節那麼簡單。 有時候會發現最初的想法是錯的。 無數的人像作品, 在x光照射之下, 會發現面部輪廓修改過, 嘴的位置也移動過, 諸如此類。

這就是我們應當學習的榜樣, 編程也應當遵循同樣的做法。 想要假設軟件的規格設計完美無缺, 這顯然是不切實際的。 預先接受這種現實對你有好處, 寫程序的時候就會有所準備,隨時應對可能發生的設計規格上的改變。

(大公司很難做到這一點, 這又是一個小公司可以發揮優勢的地方。)

現在差不多每個人都知道過早優化的危險。 我認為我們也同樣應當顧慮另外一個問題, 就是過遲確定軟件的設計規格。

好的工具可以幫助我們避免這個危險。 好的語言也可以幫助你較容易地改變主意。 動態類型語言就有這個優點, 你用不著預先就指定數據的表現形式。 不過, 我認為彈性的關鍵之處在於, 它使語言具有較高的抽象度, 如果一個程序比較短, 那它就比較容易修改。

這似乎聽起來讓人迷惑。 但是偉大的作品總是精益求精。 例如, 達芬奇在國家美術館畫Genevra de Benci像的時候, 頭像後面是檜柏樹叢, 他仔細地描繪每一片葉子。 許多畫家也許認為,這些東西是襯托頭像的, 沒人會仔細看。

達芬奇並不這樣認為。 他繪畫的認真程度, 並不取決於看畫的人的認真程度如何。 達芬奇和米開朗琪羅一樣, 都是一絲不苟。 從總體看去, 那些似乎看不見的細節也會變得顯著。 這是一絲不苟的重要之處。 觀眾經過這幅畫的時候, 注意力一下子就被吸引過去, 那些原本不易覺察的細節, 綜合在一起產生了驚人的效果, 就好像一千個細微的聲音唱出的和聲一樣。

偉大的軟件對於美的追求, 也需要超人的投入。 當你仔細查看好軟件的時候, 會發現那些不為人注意的部分同樣優美。 我不是說我自己寫的軟件是偉大的, 但我知道, 寫代碼的時候,要盡量寫得清晰易讀。 有的程序變量名取得醜陋極了, 有的程序行縮進亂七八糟, 讀這樣的代碼真能讓我發瘋。

如果把黑客僅僅當作代碼工人的話, 那他會像工人挖水溝一樣從一頭乾到另一頭。 但是如果把黑客當作創造者的話, 我們就必須考慮靈感的因素。

編程序的過程和繪畫的過程類似, 也會有起有落。 上新項目的時候, 一天干16個小時不知道累, 也有時候, 無論如何都提不起興致。

這種狀況也必須考慮在內, 你應對的方法不同, 效果也會不一樣。 當你開著手動檔汽車過山的時候, 有時候為了防止拋錨, 不得不鬆開離合器。 鬆開離合器可以防止拋錨。 在繪畫和編程之中, 有一些是關鍵的東西, 另外一些是常規的工作, 留下一些容易作的工作, 等你厭倦的時候, 就做這些較輕鬆的工作。

比如說, 在編程時可以故意留一些bug, 我比較喜歡找bug。 這時候, 黑客這個詞的含義可以說恰當極了。 你面臨的問題總體上是有限制的, 你要做的就是解決掉它。 假定你的程序應該做x, 結果卻做了y, 哪裡出了問題? 你可以斷定最終一定是可以解決的。 這個活跟刷牆一樣, 是不錯的調劑。

繪畫不僅可以教我們如何處理自己的工作, 還教我們如何協同工作。 過去很多偉大的作品都是由一群人共同完成的, 儘管在美術館的標籤上可能只寫著一個人的名字。 達芬奇在Verrocchio 的工作室當學徒時, 就參與繪製<<基督受洗>>中的天使。 這樣的事情當時很常見。 當米開朗其羅堅持要自己一人繪製西斯廷教堂屋頂的人像時, 就被認為是很不得體的事情。

就我所知, 畫家們一起作畫時, 他們並不是一起畫一個共同的部分, 而是一個主要畫家畫主題人物, 他的副手畫背景和其他部分, 絕對不會有人摻和別人正在畫的東西 。

我認為這種模式也適用於軟件開發, 不過別走得太遠。 如果一段代碼有三四個程序員分別寫過, 那麼沒人真正對它負責。 結果就會變成公用房間一樣沒人收拾, 又冷清又灰暗。 正確的做法是把程序分成嚴格定義的模塊, 每個模塊有專人負責, 仔細設計模塊之間的接口, 使之盡可能像程序語言本身那樣, 精確地表達出來。

軟件和繪畫一樣, 都是為人而做的。 黑客也應當像畫家一樣, 努力創作出偉大的作品。 你必須為用戶的立場著想。

我小時候, 就听人講要學會從別人的立場來設想。 意思就是做別人想要你做的事情, 而不是做你自己想做的事情。 這當然給” 換位思考”這個詞帶來了壞名聲。 因此我一直不願意這樣做。

可是, 我錯了。 換位思考確實是成功的秘密, 這並不意味著放棄自我。 理解別人的觀點, 並不是說你要按別人的興趣辦事。 在某種情況下剛好相反, 舉個例子, 打仗的時候, 理解敵人觀點, 其目的恰好是要反其道而行之。 [4]

大多數創作是為人的, 你得理解人的需要。 差不多所有偉大的作品主題都是人, 因為人最感興趣的, 就是人類自身。

好程序員和偉大的程序員之間的唯一的差別, 就是體察別人的能力。 有些程序員很聰明, 但論到”換位思考”, 則是完全的自我主義者。 這樣的人不可能設計出偉大的軟件[5], 他們從來不懂得理解別人的觀點。

判斷一個人換位思考的能力如何, 最好的辦法是看他怎樣向那些不懂技術的人講解技術問題。 我們大概都見過那樣一些人, 不管多麼聰明, 這件事情上卻是糟得很。 如果有人問, 什麼是編程語言, 他們會說, 呃, 就是一種高級語言, 能經過編譯器處理產生目標碼。 高級語言?編譯器? 目標碼? 不知道編程語言的人, 難道會知道這些東西?

軟件的目標之一, 就是解釋自己。 你要寫出好程序, 就應當知道用戶對軟件了解甚少。 他們用軟件時, 全無思想準備。 如果軟件的行為剛好合乎他們的設想, 那就最好了。 別指望用戶會去讀操作手冊。 這方面, 我見過的最好系統是早期的蘋果, 那時候還是1985年。 蘋果乾了所有軟件都做不了的事情, 那就是能正常運行。 [6]

源碼同樣也應當解釋自己。 如果讓人回憶關於編程的名言, 經常提到的是結構化和解釋語言初期的一句話:

程序寫出來是給人看的, 碰巧機器也能運行。

你不但要為用戶設身處地地著想, 對讀者也是一樣, 因為讀者可能就是你自己。 好多程序員寫了程序, 過半年再看, 簡直看不懂究竟是怎麼回事。 我就見過有幾個人因為這原因放棄了perl。 [7]

缺乏換位思考的能力彷彿是高智商的特徵, 尤其在某些地方, 這都成了一種風尚。 但我不覺得真的有什麼關聯。 數學和自然科學和人類感情無關, 這些領域的人顯然都很聰明, 於是乎高智商就和”不通世故人情”掛起構來。 事實上好多平常智商的人在這方面也不行。 看看脫口秀節目裡那些站起來發問的人, 那些問題問的, 真叫拐彎抹角, 主持人得重新梳理一遍, 才能搞得清是啥意思。

如果編程和繪畫寫作一樣的話, 它也一樣酷嗎? 畢竟, 人只有一次生命, 最好是做有意義的事情。

這問題真難回答。 在贏得名氣上總是有很大的滯後。 這就好像遙遠的星星發出的亮光, 要經過好多年才能到達我們眼裡。 繪畫行業光芒四射是因為500年前就產生的傑作。 那時候,沒人會像我們現在這樣看重這些作品。 我們現在所知的Urbino 公爵Federico daMontafeltro先生的形象, 是從Piero della Francesca的作品裡的高鼻子男人哪裡得來的。 這在當時的人眼裡看來, 一定是非常奇特的。

所以當我說編程沒有繪畫那麼酷的時候, 我們應當記住繪畫在它古老的光輝年代, 同樣也不見得那麼酷。

我們可以自信地說, 現在正是黑客事業的光輝年代, 在大部分領域, 偉大的作品誕生很早。 1430-1500年代的繪畫現在仍難以超越, 莎士比亞彷彿生來就是戲劇家, 把這門藝術推進到如此之高的程度, 以致於後來的劇作家都生活在他的陰影裡。 Albrecht Durer之於雕刻, 奧斯丁之於小說, 也是如此。

一次又一次, 我們看到同樣的模式。 新的媒體誕生了, 人們熱情高漲, 短短幾代人就把它的能量發揮到極至。 黑客事業似乎也正處於這樣的時期。

達芬奇時代的繪畫行業並不酷, 是他的傑作造就了繪畫行業的酷。 黑客事業之未來, 全依賴我們今日之創造。

作者註:

[1] 照相術的出現, 毀掉了畫家的日常工作。 歷史上很多畫家靠替人畫像維持生計。

[2] 我聽說微軟不鼓勵員工從事開源項目, 業餘搞也不行。 不過現在有那麼多黑客都在做開源項目, 這種政策也許會令他們難以招募到很多一流程序員。

[3] 大學所能學到的編程技術, 其狀況相當於你學到的關於讀書, 打扮或者約會的知識: 你上高中那時候的品味多差啊。

[4] 這裡有一個”換位思考”的例子。 在Viaweb的時候, 如果在兩個選擇之間下不了決心, 我們就會問: 我們的對手最恨什麼? 當一個對手在軟件裡加了個沒用的特性, 這個特性我們沒有, 他們就在媒體 上大作文章。 我們當然也可以解釋說這個特性根本是廢物, 但是我們還是決定也實現它, 因為這樣的話, 對手會更生氣。 於是當天下午我們就加上了這個特性。

[5] 不包括文本編輯器和編譯器。 因為這兩樣東西黑客自己也天天用, 自己就是典型用戶,所以用不著了解別人的觀點。

[6] 差不多如此。 他們在內存使用上弄巧成拙, 產生好多很麻煩的磁盤交換。 幾個月後, 我買了個新驅動器加上, 這問題就解決了。

[7] 給程序加註釋, 並不是增加易讀性的好辦法。 我把Abelson和Sussman的話再發揮一下:程序語言是用來表達算法的, 碰巧也能在機器上運行。 好的編程語言, 表達軟件的能力比英語更好。 只有在代碼含義復雜難解的地方, 才有必要加註釋, 就好像高速公路上急轉彎的地方才會有警告標誌。

感謝Trevor Blackwell, Robert Morris, Dan Giffin, 和Lisa Randall閱讀本文的草稿, 感謝Henry Leitner和Larry Finkelstei邀請我講話。

星期三, 2月 16, 2011

maxscript 裡對物件 transform 的控制

max裡中代表物件在3d坐標中的位置的transform是經由object transform跟物件本身的transform推算出來的。


transform 是一組由四個向量組成的陣列值
在MAX中可用
matrix3 1

的到如下的東西(就是 matrix3 預設值啦)
(matrix3 [1,0,0] [0,1,0] [0,0,1] [0,0,0])

而transfrom這東西在 get 和 SET 時給你的都是以世界軸為主,
所以在設定時就相當的方便,

就算你要要設定父物件是a物件的b物件的位置,想要他對齊一個c物件,你也只須要寫一行

b.transform = c.transform

就搞定了,而不用去管c物件有沒有父物件。


但如果你遇上了想讓物件跟pivot二個不一樣時,那就還要借助上object offset 這個 transform

在設定 rigging control 時
很常會遇到一個情況就是…例如:
spine的控制器對齊spine骨頭之外,外觀要對齊世界坐標軸向,
我們可以用
spineControl.transform = spineBone.transform
之外再加上
spineControl.objectoffsetrot = (((matrix3 1) * inverse spineControl.transform) as quat)
就可以讓控制器在"外觀上"是和世界標對齊的~


ps: 最後的那個 as quat 可以不用寫,max會自已幫你轉換。

星期二, 11月 16, 2010

測試在 android 發文章

自從買了之I9000之後,才發現原來 android 系統已經很成熟了。用 android 系統的經驗讓我很想學如何開發 android 的程式。
或許也是因為 apple 已經跑出來一套系統讓g家參考。可是因為我不在賈不思的現實扭曲力場之中所以從來就沒考慮過 iphone。

Published with Blogger-droid v1.6.5

星期二, 10月 26, 2010

好樣的 Arnold (不是 android 喔)

Arnold 在很久之前是一個很神秘的算圖引擎~
打從它在max平台上就沒幾個人真的有辦法拿它來實作什麼東西。神秘到了極點啊,在那個GI還正開始在算圖界發光發熱的時後,只要是這種新的可以算gi的引擎大家都非常的關注!
那時後這張圖不知羨煞了多少人啊…


都忘了是max幾版(2.5?3?)的事了… 圖出自pepeland


不過…
之後它就消失了…(暗!進介面圖都沒看過,文字命令列也沒有,啥訊息都沒有就不見了),而且final render,vray,巴西等等的算圖引擎大家也都研究不完了就沒人再理他了…
就在大家都忘了有這一號 renderer 時…它卻又出現了,這一次就直接丟了個動畫片出來…
〝食破天驚〞這部電影的算圖引擎就是 Arnold !!!


這圖的版權一定是sony所有的了…



從此之後就開始一點一點的,Arnold 的風聲或是跟其他算圖引擎的比較圖就被po出來了
像是 這個 ~似乎是開始為出道做準備~

果不其然之後官方自已開說明會了 XD

你可以在這二個影片裡看到有關於比較詳細的 Arnold 介紹,
這可是第一次的官方展示會喔~~

Part1
http://www.vimeo.com/15878348
Part2
http://www.vimeo.com/16155555

影片中重點的部份其實在投影片上都打出來了。
像是 Arnold 是啥鬼這張投影片我們可以清楚的看到列出了主要的特點

  1. 電影級的光跡追蹤算圖引擎(第三點中有說到是純的光跡追蹤,沒有混用scanline或啥有的沒有的算法)
  2. 物理基礎的蒙特卡羅路徑追蹤
  3. 對diffuse或是glossy等等的不須要做快取
  4. 支援多平台(xsi本身就有多平台)
  5. CPU為主,多緒支援,SIMD加速
    Soild Angle 跟 Sony Pictures Imageworks 共同開發 (打一下廣告應該的)

優點:

  1. 大幅度的簡化流程!(沒有其他檔案或是快取…沒有快取耶…真的假的…)
  2. 單一算圖品質(沒有啥產品級算圖設定,草圖級算圖設定這種鬼選項)
  3. 完美的影子(不用 shadows map )
  4. 漸進式算圖
  5. 不須用記憶體來存 lighting/GI 的資料

或是在流程上的支援

  1. 高品質的動態模糊
  2. 網路算圖,可自由編寫 shader
  3. 支援 sub-d surface
  4. 可以算很高的細節的髮線
  5. 分散式/程序式的載入模型 (在3d軟體裡是 low 的 model , 在算圖時期切換成高品質的 model )
  6. 貼圖快取

影片2是解說 SItoA 這個外掛。
特別的是他們用 opensource風格的方式來管理、開發從 XSI 到 Arnold 的外掛。只要是 Arnold 的客戶或是測試用戶,可以直接存取以svn方式管理的 SIotA 開發樹。

影片中也不難看出 Arnold 在漸層式算圖中的實力,目前沒有訂價,但主講者說不會比RENDERMAN 貴 XD。

看完影片後才知道後來有那麼多影片都已經用上了 Arnold 了啊…
希望可以早一天看到他開發出給其他平台用的版本,不要只有xsi得天獨厚,明明一開始就是在MAX上的東西啊 q_q …機車的XSI。


報告完畢~

星期一, 6月 14, 2010

玩具總動員3 觀後感~

難得我也有寫開箱文的一天。

我要寫的東西不是3c產品但也跟3有關。

是最近上映的玩具總動員3。

事實上我對玩具總動員1跟2都沒那麼有好感。

Pixar裡我最喜歡的是瓦力跟汽車總動員。

所以可以提早看玩具總動員3其實我也沒多興奮…(是滴,當然我就是抽到首映票的那一群少數人…)而且當天還下不小的雨,連老天爺都擺明了叫我不要去看了。

所幸本人有者東西不吃完會被雷公劈的處世態度,當然就不可能白白的浪費電影票,下著雨,也是硬著頭皮(天知道我有多懶得)去。

也還好我對玩具總動員3沒任何興趣,所以網路上的電影片段我完全沒看過。

也不知玩具總動員3大致上的劇情是什麼,我一直覺得這樣的情況之下是看電影的最佳狀態。

如果導演夠厲害,他就有辦法讓你的心一直在這些角色的身上。

玩具總動員3在這一點做的很好。從頭到尾幾乎我都沒有自已的想法,就是一直被導演用鏡頭牽著走,我喜歡這種感覺。只有二個地方被我逃脫了。但這會雷到(一點點而已),所以之後再講。

故事的舖陳很棒,我不知道怎麼形容這種情感。編劇群定調的很成功。或許在這些年之中編劇群裡有成員也經歷過相同的事,才會這麼深刻的呈現在電影上吧。

這部片主要就是在講主角跟玩具們之間的感情(不是前二集都是這樣嗎),該放手時放不開,但知道無法挽留,放開才是對雙方最好的方法。暗…好像在談戀愛!

不過在這部電影裡當然不會搞成戀人之間的那種愛,而是像家人跟家人之間的親情。就是全心全意的只求對方好而不求任何回報。畢竟戀人之間可能可以用肉體來回… 咳咳…

看這部片會掉淚,不過還好,記得看imax版的就會有大眼鏡可以遮,所以可以不用怕。哭的點也應該離散場還有一段時間,不會太明顯。

劇情就不要講太多了。電影要賣的就是這個了,說穿了就沒意思了。

技術面最厲害的,就是讓人忘了技術的存在。

關於玩具總動員3的技術面就沒啥好說的。基本上你根本就不會去體認到所有的東西都是”算”出來的這件事,不管是在垃圾帶的拉扯,焚化爐的火燄特效,人物動畫的活靈活現,場景中每個物體的貼圖質感…等等,都好到沒話說了,很多東西如果不是因為他的造形上有刻意去做出卡通感,色調上偏重繪圖感,我想應該是看不出來是照片或是CGI了。在電腦繪圖的領域也應該沒啥是pixar做不到的了,那麼多電腦圖學的東西都是這家公司的大老發明的。不知道在up裡用上的 point cloud 的gi render法在這一次的應用上又發展出了什麼延伸。希望今年siggraph上pixar會再丟一些更高段的應用法給我們聞香。

忘了提到,這次有依照慣例,拿來熱場子的短篇動畫作品。

這個我講多一點應該沒關係~哈。

這個故事一樣很棒。在創意、手法、跟言之有物這三點上都很成功。

它用了手繪動畫跟3d動畫結合來呈現這個短篇動畫,故事本身則是在講二個相反的個體之間因為不了解而產生衝突。

但事實上這二個不同的個體只是同一種事物的一體二面。

角色主有二個,一個是白天,一個是黑夜。這二個角色是手繪,而3d動畫的部份則是以這二個角色當做mask,只顯示在這二個角色所佔到的畫面內。

所以動畫不但講出了想講的東西,在呈現的手法上也明示了電腦動畫跟手繪動畫本來就是一個事情的一體二面,高招。

中間有一段有講話的部份,我覺得不要講會更棒。或是該段只要有一點點,點到為止,其他的讓觀眾自已去解讀會更好,不過那當然只是我個人的想法。

最後談一下讓我跳出導演掌控的二個地方。第一個是在一開始,我個人的問題,我還沒入戲~第二段是那個小鬼很開心著在玩著玩具的…算是回憶吧。那一段讓我覺得在情感上假假的,因為現在的小孩好像不會做這種事了。但也或許是我沒經歷到。

以上就是我的開箱文了,看不看當然是隨你,只希望會讓你對這部片多感興趣一點。而我要來去修正我的pixar最愛排行榜了~

星期五, 1月 29, 2010

importons 和 Irradiance Particles

暗…好久沒發文了說…也不知道要發啥,有了plurk之後就一直在噗…都沒在寫 blog…最近翻了一篇文。是跟mr有關的,有興趣的人就看一看吧。英文高手們就不要來亂了…

==以下是翻譯文===========================================

mentalray 3.6 +新增了importons和發光粒子功能。
這裡一些測試和說明。最後~你需要有一個 geoshader 以啟用這個新功能。
Importons是執行計算為主導的抽樣貼圖。(不知道怎麼翻)
它們可用於為主導的光子映射功能,作為合併的光子。
也就是說,光子接近 importon 將被保存到貼圖上,其他的就直接捨棄。這將導致光子地圖的資料量大減,但卻很精確,因為我們直接捨棄對最後成像沒有很大的影響的光子,因此我們有更多的光子密度分佈在我們需要的區域(好吧,光子不是真正的'捨棄..當一個光子被丟棄,其能量被重新分配給附近的光子)。
為了讓 Importons與光子合作,你必須設置global.illumination捲廉下的merge參數為零,也要在importon捲廉下設其 merge參數為"非零"的值這會告訴mentalray使用Importons合併光子,而不是一個固定的合併距離(如果gi捲廉下的merge參數設成非零值)。
Importons在importons階段被射出,此一階段發生帶光子射出之前。一旦光子貼圖保存好了。 Importons就被捨棄。在verbosity中,你會發現有多少光子合併以及有多少被保存到貼圖上。如果使用'density'參數,則 Importons發射取決於render的解析度大小,也可以用'emitted'參數任意的發射。
當使用Importons與光子地圖,'traverse'選項要勾選。在這種模式下Importons不會被物件阻擋,會持續繼續計算任何進一步交叉區域的重要點。
最通用的實作Importons方法就是打出了大量的光子。光子的問題不在於發射光子而是光子貼圖:如何取得、平衡,儲存和相互共享。
一般來說,在32位元的作業環境下,存儲多於1千5百萬的光子在一張貼圖,還是有些問題。首先,貼圖可能大到200/300mb或是更大,mentalray會在試圖保存貼圖之前先最佳化它…然後mental ray就會就當掉。現在讓我們回到問題點上,為什麼我們要發射1千5百萬個光子…?
一般來說處理光子時有如下二個技術手法。
在大體的的燈光情況下使用一個底解析度的光子貼圖,然後利用FG來得到細節的部份。
利用高解析度的光子貼圖來準確地處理打光的細節,然後利用FG來產生接觸的陰影等等的細節。
現在,我們有第三個解法。
我們可以用光子與Importons合作,就可以達到有準確的光子反彈、進而收集到很小的細微的細節。
舉個例子。
我在一個封閉的box裡發射了5百萬個光子。
光子發射計算時間不超過30秒。
我的工作平台是在二台雙核心分佈式算圖的環境上。
光子貼圖算好了,它的大小約為102mb。這剛好是我DBR渲染所能負荷的極限了。我要等待貼圖被傳送到第二台電腦上,雖然我的場景案很小。最後等我第二台電腦拿完那個1、2百mb的光子貼圖時,第一台已經render完成了。就…浪費了渲染的時間。
再來看看結果,那些我們用光子貼圖產的經典render圖。就…很low的細節,只要看看盒子下方的暗處,那個影子有多不自然。
http://img377.imageshack.us/img377/485/impphotonysd6.png
現在,我們可以嘗試使用Importons。全密度。和merge參數為0.05(公分,而光子半徑是1公分)和勾選traverse。
http://img379.imageshack.us/img379/6163/impmergingverbosityzd1.png
光子貼圖現在是3861kb。
如上述,,我們可以看到只須要有約200.000光子分佈於重要的、對成像影響較大的區域上。由於光子的分佈是以importance為基礎的,我們打出了足夠密度的光子用以涵蓋所有的區域,以便當通過importons合併後,仍然有足夠的光子可以取得細節。只要看一看立方體的陰影,沒有用 importons和有用importons的差別。
http://img74.imageshack.us/img74/6382/impphotimplc2.png
(編輯:由於importons用於合併光子,用完就丟,只有光子貼圖會被保存下來。這意味著,可以用maya的 photon map visualizer在視埠中直接看到有用importon跟沒有importon的photon分佈情形。 :)
================================================== =============================================
此外,我們也可以單用Importons、不跟光子、發光粒子和用。
Beside the fact,你需要一個最小量importons來得到平滑的成像,在這裡最重要的參數(跟之前和光子貼圖同時開啟時是merge,在這情況下則被忽略)是跟踪深度。舉例~我們需要讓很多importons在場景中反彈用以得到一個完整的遍歷場景的importon貼圖。先把density 參數設為0.2之後可以向上調升。對於Depth 這個參數以2為起啟值。
發光粒子。
讓我附上mentalimages怎麼說明這個'新'的技術:
'有一段對於技術上的簡短說明:在渲染之前,
importon從攝影機視點被發射出來。他們撞擊到場景中的某點,該點帶著在那一點位置上它光照的強度資訊(當然,也有可能是間接照明
,也因此稱為“發光粒子”)被合成到一個貼圖之中。
一個間接照明pass或是多個間接照明pass,都可以計算。
演算法的本質上是以 importance-driven。在
rendering時期,發光粒子被用來計算每個成像點上的光照
;如果發光粒子只有收集到直接光照,那就
相當於一個反射的間接照明。光照也可以
在粒子的位置預先計算插值。'
參數的部份就跟FG很接近。
有一個要在粒子採樣點上預計發射多少光束量的參數。
有個在粒子的位置計算插值的方法(也有針對第二次反射的)和另一個模式。即、沒有沒有使用插值時會像brute force法來處理。
Passes 參數代表著計算光照強度時會考慮幾次的光線傳遞(反彈),就像是FG裡的diffuse bounces參數。
最後,如果您有一個環境,像是mr_sky,發光粒子將支持另一組採樣參數。
這裡有一些用來說明新功能的圖組
只有在第一張圖片完整的使用了importon + irradianceparticles。其他的只是保留了計算完的結果(GI mpas),然後再次下 render。在計算importon + irradianceparticles時花了約30分鐘,之後的每一張約花3分鐘(render大小約為1k)。
http://img396.imageshack.us/img396/2710/shot001rg2.png
http://img120.imageshack.us/img120/6391/shot060hn3.png
http://img72.imageshack.us/img72/8105/shot0109ut1.png
(importons密度0.5,depth4; irradianceparticles,680rays,2張,32interp,480envrays)
這裡有一段動畫可以看出 Irradiance Particles 有效減少閃爍的現象。
這是設定為中等細節後計算出的結果。雖然在陰影的部份仍然有一些班點。但是,這些班點不會閃爍,因為沒有每個frame都重新計算。(捆紮配備了網頁壓縮)。
http://rapidshare.com/files/107992908/output3.mov.html
================================================== =============================================
另一個特點是配備了mr3.6 +是一種先進的幀緩衝記憶體管理。說白一點:快取模式。當您在快取模式,可以render任何尺吋的圖像(甚至在32位上)。實際上,如果啟用,只有一小部份render完成的的圖像(或是說用使者的framebuffers)是存在於記憶體之中:newly rendered tiles and tiles recently accessed。
這個模式應該只用於btach渲染(如果在maya內用render view又打開快取模式,maya會掛點…不過…在viewer裡render大尺吋的圖好像也沒啥意義)。我剛剛在32位系統上render完一張 20k的圖,存成32bit。比其他方法慢,這個模式應該只用於如果mental ray 沒辦法建立一個很大很大的framebuffer(一般來說在32位元系統上是指超過4K的圖)。
鋼筋混凝土0.2信息:選項:蛋白原號負責管理緩存
鋼筋混凝土0.2信息:選擇:圖像類型插
鋼筋混凝土0.2信息:0 rgba_fp是
鋼筋混凝土0.2信息:相機:焦距1.37795
鋼筋混凝土0.2信息:相機:孔徑1.41732
鋼筋混凝土0.2信息:相機:方面0.8
鋼筋混凝土0.2信息:相機:第16000 20000
================================================== =============================================
二個注意事項在於使用Importons+發光粒子和Maya2008SP1。
不要用任何maya內建的shader:
'Suppress all Maya Shaders'這個選項記得勾選。在 shading engine 節點(mia_material)中的'Export with Shading Engine',這個選項要不要勾選。
上述檢查事項也要對燈光做一次。'Suppress all Maya Shaders'選項要勾選,要提供自定的 light shader (MR sky protals不錯用)。
最後,在render setting中,到 Translation->Customization中把'Export State Shader'的勾選取消。
最後~~如果想要更進一步的描述和參數說明,請閱讀軟體手冊中 geoshader 一節。
也有64位版本(刪除.X64的後綴)。
祝你玩的愉快!
Max

dagon1978

2008年4月21日,下午3點27

不錯,但老實說,我看不出跟這樣跟使用FG+GI加上AO和色溢有什麼差異。
你可以用skyportals得到物體交接處的陰影,這陰影還是area lights把室外的環境光傳遞裡室內得到的結果,如果你再把這結果拿來跟AO做出來的色溢混合還可以得到更進一步的結果,帶有色彩的物體交接處陰影,這樣的處理手法會導致後我們得到跟用發光粒子和importons這個手法一樣的結果。
而且更快~
我認為在 interpolated IP 你是正確的。
我想多說一些關於這一點,我認為暴力計算IP是一個很大的改善(比FG跟path tracing的暴力法快多了,甚至偽一體化),但我也對這種功能未來的方向擔心。
OK,現在我們有一個很好的起點(importons),它們公正呈現(或者類似這樣)renders 。為什麼不考慮看看漸進跟踪(像是在VRay裡的lightcache和PPT ...而明年他們有一個新的互動/逐行的render引擎基於此)?
就是我想說的是:我們不能從mr的開發者那裡得到回應、互動,我們看不到未來mr新功能的方向在哪裡,這肯定是不好的,因為很多時候他們不會採取對user正確的方向,恕我直言。
mental ray的開發者們,你一定要聽user的需要,如果你想進步!拜託!
現在,從另一面想,我們有ZAP(mr大濕(誤)),所以我可以跟他談論著色,我真的相信他把所有我們所提的意見認真的考慮過,我看得到這一點的好處,現在我們在mr的shader 整合上有很好的成果,這正是目前mr所展現的成果。
另一頭,我們有核心開發(我可以裡批評很多,但我想要有點建設性),那為什麼不能有一個論壇(拜託,都2008年了!),甚至mray網站上的資訊都非常落後(mray 3.3的資訊?噢,我的...)
然後我看的到後果,...需要很多功能,也增加了一些新功能,但沒有一個有說服力...
好~再回頭想想 interpolated IP,我真的希望在下一版本做到更好,但嘿,回顧過去的問題(我說的是FG 3.5版時的 interp 問題,從第一天我用mr 3.5 上工就遇到這個問題,直到現在都沒改進…3年了耶…?)這難免令我有點擔心...
現下,就我可以理解的部份(我不是技術人員),有一些IP機制本身的錯誤,我指的是 IP 計算內插這一部份。
對光子(phootn)好的開始是:(和lightcache,所有好的演算法中的二次射線)如果你需要一個插值解法,您可以用一個平穩和快速計算的二次射線的散射光,並用良好的主射線演算法來添加細節(在mr就是fg,在vray就是irradiance cache)
現在的IP:您可以射出importons為主要射線和二次射線,但你不能單獨控制其中一項要品質!
恕我直言,這對IP及其插值計算這是大問題,如果你想有一個良好的 GI 就要射出很多importons,許多importons =要射算大量的射線,射算大量的射線+很多importons =很長的 rendertime。現在你可以有一個近乎完美的interp IP算圖。但rendertimes非常接近沒做interpolated 解法的!
在未來幾週我會做一些比較,這樣您可以比較容易看到。
因此,如何解決?
恕我直言 就是分開主要次要射線的控選項!所以有兩種方法可以選擇:有光子+FG的方法(原本mray方式),和另一種VRay(和海龜和FR和邊疆區...)式,在核心裡獨立主要和次要射線!
這三年來我一直試著要求要有這個功能...我不明白,為什麼從來沒有聽有人說過它!烏龜(另一個renderer)的開發人員細心多了!因此,也許mray核心的一些技術限制導致你無法做這個改變,但是可以讓我們知道。後找尋另一種解決的辦法。
我不希望把這些討論開在另一個討論串,Max,希望你們能明白我想說的東西,我不是要批評開發人員,我希望這麼做有建設性,我想要給你們user的回應,我想做要求新功能等
但如果你不喜歡這樣的言論,我可以殺掉這一篇,並開啟另一個討論串...
thanx
mat

==翻譯結束===============================================

之後我再補上mr help裡關於 importons跟 Irradiance Particles的中譯

星期六, 8月 29, 2009

SIGGRAPH 2009

第一天…

先來個暖身po…
飛了快整整24小時…終於到了這次siggraph所舉辦的地方…紐奧良… rabb_048
基本上今天沒啥事,主要是去註冊拿狗牌而已。
所以下午就從飯店走去吃個午餐順便走去會場。
會場外觀

會場內部長廊





這個會場真是他媽的大…走了好長的一段長廊之後才到達要註冊的地方。
註冊點


已經可以看到在佈置了,不過我們還不能進去,只能看而已。
目前只有坐飛機坐真久的這個感想而已
明天就開始了,我會持續的po圖的…希望到時後不要因為暗拍不太起來。
今天就先這樣吧~下午走了好久,還去買了水…(一瓶水要2美元是怎樣…),我先來休息 rabb_023

==第一天的分格線============================================

 

第二篇來嚕
今天主要要聽的有二個。
上午的場次是production session的Building Benjamin Button:A Blending of “Technique-ologies”
這個會場有夠大,大到好像可以放一台飛機了。



請到了四個dd的人來講,不過這場講的東西其實在網路上都已經有很多相關的文章跟貢料了,
反而感覺沒什麼。
基本上他們還是請很一個很屌的人物塑模師來把Ben在老年時代的實體模型
建出來,表面的材質使用的是死理控。再把模型拿去用light stage v3 掃瞄成3d模型,並抽
離出diffuse等貼圖。利用paul的方法來重新打光。但是這個結果並沒有直接應用在電影上,他
們是利用這個結果來校正他們的skin shader。
在表情的部份還是要有動畫師去調整表情,因為他們用(開發)的系統沒辦法辦別”笑”裡所潛藏的情緒。
他們認為最難做的是眼睛,他們有特地做眼睛的rig讓眼皮會跟者眼睛牽動,而睛球的shader也做的很精細,在瞳孔跟眼白之間會有不同的specular等等
嘴吧的部份…因為布來得彼特的牙齒太白,所以他們要找一個牙齒黃的來做Ben80歲時的貼圖,最後是用了其中一位演講者的牙齒,他說從那之後他就戒煙了,哈。
而把digital的頭接到真實演員的身體的這個過程,其實非常的依賴人工去製作…
以下為偷拍圖…我還想拍的時後就被工作人器制止了…
所以…就沒辦法錄影或拍照給大家看了。

聽完就已經10點15分了,接下來要聽的場次是在下午的,離12點30我們要集合的時間又還早,所以找了一場 Animux Free Software for Animators 聽
這一場有三個主持人。 一個是主要把持animaux這個 project的 Mark。一個是好像在 blrnder 圈有名氣的叫 Jasson的人,他組了一個十幾人的team,用了animux做了一段動畫。
基本上我對這一場還蠻失望的。
他講的時間是11點到下午1點,但是我聽到12點15就要去集合了。而在我有聽到的部份的四分之三,他都在講用免費軟體有多好之類的…animux有很棒的功能,很簡單就可以讓USER使用之類的鳥話。讓我一整個有被傳道的feel…
我剛剛還忘了講第三個主講者對吧,其實他不算是主講者。她有點像是…第四台的廣告中的那種親身使用見証人之類的角色。就是講了一段她一開始用blender 不好用,然後發現網路上很多教學跟資源,之後他習慣了ui之後就覺得blender非常好用的親身經歷…(要是我自已付750美金來聽這個應該會幹的要死…)
之後就是播放用blender做作品(好像有一段就是第三個講者的作品)。
結果他為了在animux上播放沒聲音,光整調coder就選了好久,搞了快十分鐘,現場還有人問說”有沒有別的播放軟體可以試”,反正他最後還是搞出聲音來了,但是作品一播出來,我覺得沒有特別好…冏rz
後來又播了那個Jasson做的動畫…十幾個人做的品質好像沒有二個人做的來的好,剛好時間也差不多了,我就很失望的離開了。
不過在我要離開的時後他就開始講一些比較有趣的東西了(淦…)
開始講到animux裡整合了什麼東西可以在前製時用,在製作時是用哪些軟體等等,又講到了一個叫 windos project的東東。說是 blender 的開發團隊跟aqsisi合作的專案,用以測試一個叫 blendertorenderman的東東。也有提到 shaderman – next ,就是之前的 shaderman,好像有再開發下去的樣子,不過我急著走了,沒有很認真的聽…
中午吃午餐人爆多…排點餐排了二十分有才等到,叫來了之後發現可樂甜的不得了…難怪美國人的身材可以走樣到一種程度…
吃午餐的地方

下午主要要聽的是 making it move 的curse,但是他是三點45分開始,所以就又找了1點45分開始的curse來聽。
所以我跑去聽 splash in to pipline。主要有四段,其中一段是馬達加斯加2的水波動畫的制作。
不聽還好…聽下去整個人變的超想睡的…一整個都太技術面了。主講者講一講,然後就秀一堆公式…Q_Q,整場都是這個樣子。
最好是我都會了解DB TREE是改良DT TREE之類的三小演算法…
還有啥 Q1+Q2+Q3=0之類的可控製參數…Q_Q
反正這一場是失策了。而且搞的我整個人超想睡。
下午3點45分,making it move 的curse的這一場比較沒有上一場那麼誇張,雖然也是技術面,但是比較偏向製程的部份。
這一場也是分四段。第一段是迪士斯的一個短金髮,瘦長的屌屌的男生來講。主要是講他寫的一個在maya的可以做實體分割模型的外掛。
第二段是講up裡的氣球的作法,他主要用的東西好像是一個叫ODE的物理模擬外掛(有熟maya的可以出來指証一下嗎),然後有做了一些rig讓氣球好控製。在線的部份也有做了一點假。
第三段是講 fight night 4 裡的人物物理動畫。他們藉由玩家輸入的指令來控制animation rig,然後animaiton rig會對物理碰撞做反應,計算的結果再影響animtion rig跟算圖。他們也對肌肉做了flex map,就是用權重把可以flex的肌肉部份畫出來。還有做了一個機制可以摸擬肌肉用力的感覺。就是先把肌肉很用力的時後的棤型弄出來,再轉成 normal map(全身),之後把肌肉群的區分出來,用來個別的控製該區的normap 強度。
最後是講alien vs monster 裡的 bob 這個角色。
他一開始就提到最大的問題是… bob是一個 character還是他是一個 effect …
最後bob依然算是個角色,不過為了達到 bob能做到的動作,他們做了一個fig,而動畫師要key bob這個角色的動作之前要經過訓練課程…
bob的rig分成了幾層:
high-res (沒有手)
neutral以(沒有手)
isosurface (有手)
最後再依上面上個去混合出最後的blender version
由於bob最後是用isosurface算出來的表面模型,所以每一格他的mesh都不一樣,這樣導致了他最後算圖時會閃,所以又用了一些手法來處理了三個部份,不過我只記得normal map平滑這一部份…其他二個部份忘了。
該主講者最後說他一共花了是二年的時間在bo身上,寫了 15000行的code來做出來bob該有的動作,他花在bob的時間之多都可以娶它了…
最後想說可以離開了,沒想到還有一場6點到8點的可以聽。是siggraph2009王部的技術論文快速介紹,聽得我都打盹了…
聽完已經8點了,就又直接趕去台北同鄉會…


坐接送巴士去


台北同鄉會實況…

到了會場發現paul已經到了,我家k先生就跟他聊了起來,
基本上我們下星期一要去他那裡做light stage的測試,所以k先生就又跟他聊了些細節。


這裡的部份我就不多講了,其實就是一些社交場合會作的事情,跟我不太對盤。而且我超想睡又還沒吃晚餐,進來時喝了一小杯可樂弄得我全身酸痛,所以就先離場回飯店休息了。就算是如此,回到飯店也已經10點了…再弄一弄東西,po一下文就瞬間2 點了…x的…要睡了,明天也會是要聽到晚上8點的行程…今天這一場因為都是聽talk,所以沒拍啥照,明天就會開放廠商攤位,到時就可以去參觀了,明天再 po嚕~晚安。

==第二篇的分格線==================================================

 

第三篇來嚕~
跟昨天一樣7點50就出發到會場,程式那邊的人有要聽的course在8點30分。我則是要去廠商攤位逛。沒想到廠商區要9點30分才開放…
還沒開放…


進場前的盛況

時間還沒到一堆人已經擠堆要進去了。好笑的是入口有二個,但是所有的人都擠在這一邊的,因為Pixar的攤位在這一邊…
一開放入場我前面的所有人幾乎都跑去排Pixar的攤位要拿贈品,聽說每年都是這樣,其他廠商好像已都見怪不怪了。小弟也不免俗的去排隊了。


PIXAR


排隊的人…

拿完了海報,大致上就去逛了展場一圈。
hdri攝影機

fromz的攤位

臉部mocap的東東


google…?

DD

還有講座的時間表

VUE8

MAXON

blender

Autodesk

回到AUTODESK的攤位時,XSI已經講完後,MAYA剛好講到一半,
我就在那裡坐著把MAYA的DEMO錄完,有講到一個叫MAYA COMPOSITER的東西,
不過不知道是不是只是像MAX可以包成CB的輸出那樣的功能。
接下來就輪到LOUISE來DEMO MAX 2010了,不過MAX的部份有遜,沒新東西,
講CLOTH的部份沒有 SAI講的好,又很快就帶過,然後有一半的時間在講MAX跟
MUDBOX、MB的整合,所以MAX的部份實在少到可憐。
MAX我也有錄,不過…因為錄到我的記憶卡爆了,而且實在沒什麼新意,
所以後來我就把MAX的部份殺了。反正DEMO的部份其實在AREA的LIVE裡應該都會有,
如果大家有去收看的話,不差我這裡錄的。
還有跑去DD的攤位看了一下,正好在講班傑明的燈光部份,跟第一天的course講的東西差不多,就沒再聽下去了。
午餐時間


在買餐點前的三個high咖
(等待youtube上傳完成之後會放視訊)
不知道是從哪裡跑來的,不過唱的還不錯聽。
午餐…我已經開始懷念牛肉麵了 Q_Q

下午的course算是重頭戲吧,要講TS4,Star Terk, 跟Transformer 2
一開始講的是TS4,從CONCEPT ART開始講起,提到他們這設計機器人的演變,非常大的那一隻機器人跟摩拖車機器等。
也講了一些CUT的製作過程。其中有一CUT是主角從大洞爬上來之後發現在上面駐守的人員都掛點了,要開直升機飛走卻遇到爆炸。我對這CUT的印象比較深。基本上背景是藍幕,而在鏡頭推進到直升機的內部時,就切換成CG做的直升機。
而機器人的部份,在跟主角有互動時,他們會用演員去演機器人,跟主角有互動。之後再把演員(有穿mocap服)的動作轉到機器人身上,他們用一種叫 imocap的技術(他們自已發展出來的)來做這件事。
Star Terk 的部份我就開始進入了調整時差的狀態…整個人變的很想睡…
我只記得有講到太空船的設計…還有負責搞黑洞的那個講者上台之後的一些片段…
基本上這個部份因為我都在半夢半醒之間,所以沒啥印象,要再聽一下錄音了…
還好第三段TF2就好很多,畢竟電影本身就比其他二部來的吸引人。所以還能擊退睡魔。
ILM展示了特定CUT的不同ANIMATICE版本。有用樹林裡大戰的CUT來說明他們在
後製時還有做了什麼事。也放幾個搞笑的片段,沒外流過的。有一個是柯博文在樹林
跟三個狂派大戰時,背後有一個更大的機器人,像是怪獸大戰外星人裡的單眼巨大機
器人那樣子的可愛角色。還有一個是彩色手稿,在深海裡三個機器人在讓密卡登復活
時,旁邊站了海綿寶寶跟派大星…
最後放了一段他們自已公司錄的影片,就是圍繞著TF2的話題在搞笑就對了。裡頭有
個CUT說到大力神的全部零件開出來之後光存檔這個動作要一個小時,所以他請這個
同事在他的電腦對大力神進行存檔,然後叫另一個同事開該檔,然後那個同事的電
腦就爆炸了(合成的),很不錯笑。
聽完之後時間是5點半,6點馬上有一場是叫作take care of your pet 的course是在講一些動畫電影裡的動物製作。
開講前

一共有分成四小段,第一段是講pixar影片up裡的那一隻天堂鳥的翅膀的作。
他一開始先講手的部份,手臂的羽毛分成5層,每層共15根羽毛,每個羽毛又作了curve deformer,有下aim constraint等等的處理,又觀察了真實的羽毛來寫了專用的羽毛shader。第二段講的是 bolt 裡的 rhino這個角色。因為牠都是待在一個塑膠球裡,所以就有特地對身體跟塑膠可以互動的部份做處理,而球本身的轉動也是寫expression下去判斷。第三段又是pixar,到三隻狗的製作,不過這一段開始我又開始進入晃神的領域…所以就又要再聽一下錄音了。第四段講的是妮可跟金剛浪合演的澳大利亞,基本上我整個人已經不行了,就離場坐巴士回飯店睡了,醒了之後就寫下你現在在看了這一篇…x的5點了…我要睡了…明天一大早又有course要聽…,我開始覺得好累喔… Q_Q

==第三篇的分格線====================================================================

 

第四篇來了~
一樣…一大早又有production session 的course要聽
主要是講fight night 4 跟gear war2 這一個作品
一開始先由gear war2的人來講,主要講的東西是這個遊戲的art direction。
從一代到二代,他們怎麼去找遊戲的art direction。
基面上他們提升了所有的品質,在視覺重點要從一代是放在四個主要角色身上拉
到整個gear war的世界觀上。
然後g2加了很多不同角色之間沒辦法共用的資料,所以利用了壓縮來減少儲存空
間。也秀了一段他們抓mocap時的錄影跟最後該mocap資料應用在game裡
的realtime game 影片。
他有提到他們的材質也是經過高度的模組化,基本上他們做了很多組基本的貼圖,
利用這個基底的貼圖去最用在很多不同的模型上。這樣應用在建築物上時非常的節
省記憶體。所有的人物材質也是衍生自同一個基底材質。這樣他們可以快速的變更
人物整体的材質。
第二段的fight night也是從美術面的大方向開始講。從他們怎麼研究真實拳擊的資
料到找到方法轉化成遊戲可以接受的作法,令人印象深刻。
他們拍了很多真實的人臉被拳擊手套打到時的慢動作動態參考資料。
有男生也有女生,一開始他播放時大家還不知道這段影片是作啥用的。只看到一個人
臉在畫面上笑,而且還是個女生。
等到拳擊手套慢慢的揮進來,打到臉上是,大家就開始發出…嗚喔的聲音,然後開始
大笑。但是心裡也會想到說,這個製作團隊真的花了不少心思在找出真實世界裡的物
理情況,因為在看了該影片之後,就馬上體會到,其實人臉在被打擊到的那一瞬間,
臉部皮膚的晃動範圍和強度遠比我心中所認為的還要多和大。
該主講者也有播放其他從不同的拳擊電影影片中抓取的圖片,抓出如何藉由指光和攝
影角度讓台上的拳擊手在畫面上更加顯眼的辦法。
另一段影片是一個拳擊手在打沙包的影片,在這個影片之中可以觀察到肌肉在打擊到
的那一瞬間的晃動程度和力道大小之間皮膚因為肌肉用力而產生的明顯變化。
還有拳擊手被打到時所噴出來的千水和血水等等,其實都是讓玩家感受到這個遊戲很
真實的重要視覺元件。
所以他們研究之後在遊戲之中加入了他們認為很重要的這些元件。
主要分成四個部份 contact、feedback,reaction跟strategy。
在contact的部份為了讓人物更有實體感跟角色之間接觸時的量感,他們加入了
Screen Space Ambient Occlusion ,不過他說這個東西很貴(須要大量計算),
因為他們是以60fps在跑。在肌肉晃動的部份他們加入了他們稱為 flex map的東西。
在feddback的部份就是加入血水跟汗水的動態揮灑系統 (dynamic sweat spary)
在reaction的方面是加入了臉部的變形 (real time的solver,從他們現有的cloth solver改良而來。)
在strategy的部份則是加入physics based scaling。即使人物大小之間
有差異(身高180公分跟身高150公分),在對打時程式也會依照其高度去改變他出拳
時的方向等等。
這一場講的很不錯,聽了之後真的覺得收獲良多。
聽完之後沒事就又去廠商攤位逛了一下。
再補上一參展廠商的圖

這個業務超認真的跟日本人講解他們的產品(即時算圖外掛),最後還講日文,真是用心…

pixar的再來一張~

n家的攤位

ati的攤位

eyeon的攤位,很小。沒啥人看,沒啥人氣的感覺…

choasgroup(正在講demo vray)

3d列印輸出的,有放很多製作好的公仔

又跑到三樓去看一下互動試的學生實作科學實驗的東西…很多我看不懂…
不懂之一

不懂之二

不懂之三

這是…體感雨傘。
他們把物體落下打在雨傘上的震動先錄製下來,再用他們做的體感雨傘,
就可以感受到被記錄下來的震動…一下開是下雨,再來是下鋼珠,最後是下麵條…

今日午餐,難得的日本料理,雖然不好吃,但是已經是這幾天吃到最順口的了


下午的場次是 two bolts and button,就是分成三個小段落,其中有二段是講 bolt的,一段是講班傑明的。
講班傑明的那一場的主題是 The Light Kit:The HDRI-Base Area Light System
由dd的人主講。介紹他們把攝影師的打光方法帶入電腦動畫領域。他們把攝影師常
用的燈光拍成hdri,然後把該hdri貼在平面上,用以模擬真實世界的燈光。
當然,如果是這麼簡單 話,你我也都會。接下來他們就開始介紹他們怎麼處理這個
貼上hdri的偽 area燈的演算法和遇到的難題,怎麼去在hdri裡抽燈光的取樣點,怎麼
去blend影子讓影子不會閃有很明顯的切線之類的。他們最後寫好的shader是只要放
好該hdri-base area light在3d空間中,該shader就會依其物理特性,燈光的大小跟
物體之間的距離來產生應該要有的光的強度跟影子的大小,模糊程度等等…真是他x的
屌爆了…,他們是用maya來實作這一套燈光工具的。
然後也提到了用mirrorball 格式的hdri來產生環境光的部份,他們在nuke裡把該環
境建出來(終於有提到nuke了,海爺~),然後帶入鏡頭資訊,再把該環境再度算成
mirror ball格式的連續的hdri序列檔來當製作動畫版的hdri,這個手法真棒,不過我
還不知道要怎麼實作就是了(海爺試一下吧)。
另外二段講的是bolt電影裡的特效部份的製作。
主題一是 interactive light of effect using point clouds in”bolt”。
迪士尼的特效人員從point cloud這個想法發展出了一種打光的工具。
其原理是把計算好的volume data bake成point clouds,把該要有的data都bake進去,
比如像是顏色、位置,強度,範圍、法向等等。之後把這些個別的點當成一個個的燈光,以
其記綠下來的法向方向法照明,就可以產生非常好的效果。而且可以動態的採樣point clouds
的資料,所以不一定要計算所有的point clouds。
他提到第一步就是整和可以bakd資料的軟体到所有effect shader跟volume shadr中,
而他們也實作了一些可以加強製程彈性的工具,像是在houdini中的point clouds的writer跟reader
(不確定是外掛還是script,反是是自已寫的就是了),在maya裡的可視化point clouds工具,
還有一個就是我上述提到的可以採樣point clouds的工具。
第二段bolt講的主題是
composite-based refraction for fur and other complex objects on “bolt”。
一樣由迪士尼的人員出來講解,主要是因為bolt裡有一個角色他都一直待在一
個塑膠球裡,而且還是個毛絨絨的老鼠。Fur跟反射跟折射給個合起來一起計算實在太費時了,
所以他們想了個辦法把反射跟折射的部份抽到後製來做。
作法是在算圖時期會自動把球在camera space裡分成前後二個物件,分別render好normal、
distort(有點像是表面凹凸的貼圖)等等的pass,再丟到shake去把他們連起來。
依照折射的公式,他講解了要保留的資料以及如何在後製時利用該實料來計算折射。
反射的部份有一點小小的不同,不過也是用一樣的原理。反正一整個很神就對了
…我覺得這一段應該要叫海爺來聽的…
之後就等晚上看電子戲院了。(6:30PM-9:00PM)
電子戲院一共分三段。一開始是realtime的部份,展示了四個東西,
一個是ps3的flower,二是ati的realtime demo,三是 一個日本人
所寫的很奇怪的東西…,四是fight night 4實際玩給你看…
第四段的比較好玩的是他們做了泰森跟 Will Wright 對打…
(http://en.wikipedia.org/wiki/Will_Wright_%28game_designer%29)
用xbox360來玩,最後 Will Wright打贏了。
之後就沒什麼了,看動畫而已,我也沒看到最後,看到8點左右持不住,做巴士回飯店了,然後就又睡著了…半夜才爬起來洗澡…冏

==第四篇的分格線==================================================================

 

第五篇來嚕~
話說我不知道每年的pixar都會發二種贈品,一是海報,一是茶壼。
其實我星期二晚上時就知道有茶壼這個東西,因為同行的同事有拿
到。一開始我還想說茶壼也沒啥,後來才發現是限量的
…有沒有這麼殘酷啊!!!!!
所以我星期三時本來就要去排隊了,可是為了吃日本料理而趕不上。
所以星期四我一定要拿到茶壼!而且今天是廠商展出的最後一天了,
今天不拿明天就沒得拿了。
也剛好一大早就有panel可以聽就又早早做巴士來到了會場…
淦…每天都是8點出頭就到會場了,上班都沒這麼早…
所以我就又到了 ballroom(就是大到可以放飛機的那個場地)
去聽 deconstructing “watchman”
講者有三人,是不同公司的人,看來watchman也是包給很多不同公司作。
第一個講的主要是講曼哈頓博士的製作,第二個是講面具人的面具製作。
基本上就是nuke官網的那個東西,不過多一點片段就是了,沒啥特別。
第三個是一個叫mpc的公司最扯…就是播放watchman的片段給大家看…
不過這一場是 panel ,所以接下來都是有一個人一直丟問題問三個講者,有提到說他們有用到三個render,其中有一個是anorld(我有拼錯嗎?)說。
我聽到9點15分就閃人了,因為我要去拿pixar的海報。
拿到海報之後就又去聽一個叫特效蛋包飯(effect omelette)的course。聽完之後又覺得應該是海爺要來聽的東西。
這一場有四段。
開講前

第一段的主題是講 bolt的立體電影製作在製作時他們遇到的限制,他們在製作立體電影的製作上遇到的因難和他們怎麼解決。比如為了讓使用者在觀看時不會感覺到不舒服,所以他們有限制在場影中最遠的物體的距離之一類的。
第二段是講pixar的人物設計,如何讓人物保持在一個很基礎的還有他們設計的人物造形怎麼影響他們衣服的版形。你意想不到的是,卡爾的衣服裡還真的有放墊肩,我以前小時後會拿來當北斗神拳護肩的那種…
第三段是講up電影中發射網子抓鳥的那一段的製作。講者是上一次講解up裡一大堆氣球rig的同一號人物。他在繩子的製作上還是使用了一樣的(ODE)外掛。
也展示他用的手法,我印象比較深的是,在該段的QandA時有個人問說”是不是有可能你所使用的外掛或工具會發行在別的3d軟體上比如像max”,然後會場的人就笑了…(淦…好心酸的感覺)
第四段是講gi joe裡有一個艾非爾鐵塔倒掉的製作過程。
由dd的人主講。這個特效主要是在houdini製作。他們利用的小胡的cloth simulation(當然有再自已加強啦)跟手工key來製作。
他們有發展一個叫PBB的系統…作用是用來計算鐵塔倒掉時的彎曲破裂。
還有溶化的特效也是在小胡裡制作。
這場講到12點半,不過我12點就走了,因為我要去排pixar的贈品,不是海報,是茶壼!!!
海報發送的時間是早上,而茶壼發送的時間是中午1點,我怕我拿不到,所以我12點就去排了。等到了一點,排隊的人潮已經繞會場四分之3圈了,如果你知道展場有多大,你就會跟我一樣覺得也太誇張了吧…還好我早早就去排隊了。
午餐吃會場的壽司。
花了13塊美金,吃到難吃的要死的食物…
在內湖的大潤發的都比這個好吃而角換算下來也才3塊美金…
心裡一整個只有淦這個字。
下午主要是聽一場卡洛林的臉部製作course。
不過很誇張的是…排隊要進場的人跟要看tf2那一場的人一樣多,
排的老長的隊伍

我還以為我看錯了…
很幸運的我有排到,因為這一場的場地沒有很大,能容納的人數有限。
主講者有二個人, 一個講的是3d列印的機器,有點像是業務,
一直在講3d列印的客戶分佈,列卬的機型等…,
講了一陣子之後才換上真的製作的人員上台講。
卡洛林的製作是先在3d裡(maya)把模型建出來,
把臉部表情的部份先規畫好要做的一整組set做好。
比如說生氣的說話,高興的說話等。
用maya把模型做出來,輸出模型成3d的實體模型,經過人工製作的打磨,上色等 做一個表情kit的3d實體模型組。
之後再用maya,拿已經規畫
好的表情的kit來組合出他們要用的動畫
在maya把臉部動畫做完之後可以輸出一張sheet表,指出有用到的臉部表情的組合。
會有工作人員依照該表格把這些表情整理好拿給動畫師。
所有表情kti加起來有12000表情(實體模型),放在一個房間裡儲存著。
此外他有利用maya把木偶臉部的零件全部折給我們看,
很精細,很棒,一整個就是很感動的感覺,那種動畫師的動畫魂完全的展露無疑。
晚上則是去 siggraph 2009 的歡迎會。星期五就結束了,歡迎會辦在星期四…?
去歡迎會場的路要經過一個倉庫~入口處

放了一堆花車遊行的東西



會場外觀

會場是個港口





會場內部…都是人啊…



看完回去飯店後,一樣又是吃完飯(比薩)就差不多了,明天就是siggraph的最後一天了,真希望早點回台灣啊。
一定要給這家商店招一張,生平第一次買酒要看護照跟在美國的第一碗泡麵就是在這裡買的

今天在會場因為拿了二個海報背了二個包包拿所以很難拍照,晚上把東西放回飯店之後才空手來~請大家見諒
來睡覺…

==第五篇的分格線=====================================================================

 

第六篇來嚕~
好不容易到了西瓜的最後一天,今天早上沒啥能聽的課。
而且廠商攤位區都撒掉了,沒得拿每報跟茶壼了。
早上去聽的第一場

這一場是講程式的東西比較多,但是有一段是講 cloudy chance with meatball的render。他排在第二段,我聽完之後就換去看要戴3d眼鏡的電影。
該場次播放的3d電影是從廣告、電影、科學研究等等多個領域集合在一起的片段,有實拍也有動畫。
3d的效果非常的好,而且人一樣很多,後來出去一看排隊的人超多。
等著要看第N的人潮


還好他有播放很多場次,不然沒看到真的還蠻可惜的。而且下一場一樣也是播放3d的東西。是pixar的 tokyo mater 3d。我們怕到時後排不到,所以一吃完午餐就又去排隊。
排 tokyo mater 3d 時看日劇的同事

看完之後還差1小時才輪到下一場次。講的是rigging。
第一段是講博物館夜驚魂2的章魚的腳的rigging。
他們混合了cloth跟softbody的simulation。以ainmator調出來的keyframe animation為主,加上simluation來修正跟加強動態。有人問說他們是以什麼軟体為主來製作他們的動畫,主講者回覆說他們有80-90%是用他們自家開發的軟體,剩下的是用maya 跟houdini。
第二段是講有關如何在把物理特性的東西應用在3d軟體之中。沒啥特別。
我聽完第二段之後受不了又很想睡的感覺,好像又進入調時差狀態的那種累(x的都第幾天了,怎麼還會有這種感覺)。而且最後一天會場的接送巴士只開到5點半,所以我就先回飯店休息了。
至此這次的siggraph之行總算是結束了
看完這次的siggraph之後覺得gpu算圖跟3d立體電影已經是趨勢了。Max應該會被淘汱…
(我去參加的course裡沒有一個是有用到max的,提到max還會有人笑…)。
接下來就是要去LA看同事搞light stage了,如果我有啥心得,我就再寫出來,沒有的話,就是到此完結嚕。
謝謝收看~(有拼錯的英文請見諒,懶的查証了…)