16 febrero
這是原文的出處
你也可以到這裡看cgg的討論串~
我翻了這二篇:
Let me start with this: PFlow and TP are VERY different. They appear to be doing the same, but they do not. So usually the decision which one to use (at least in real world production) depends on what has to be done and which one does that particular thing better.
As mentioned already, your question is very similar to "Max or Maya, and why", and the summary answer is also very similar: Max does the things you do 90% of the time easier, but lacks in those last 10% where things get hard. Maya is missing the first 10% that should have been easy, but makes the rest eaiser, including the difficult stuff. Replace "Max" with "PFlow" and "Maya" with "TP" and you'll get the picture...
You have been exposed to what used to be TP 1.0 in C4D, TP for Max is at version 3 and growing. It is VERY powerful and relatively complex for new users. It is great for breaking things apart with interparticle collisions and anything that requires mesh-to-mesh collisions and flexible rules that let you change the starting conditions while still producing a plausible result. TP tends to store its particle data as part of the mesh shape, so while doing abstract point clouds is possible, integrating TP with Krakatoa for example was not very easy. TP has a wonderful presets system (Black Boxes) for storing your work in encapsulated form and reusing later. Caching is good and baking to scene objects is directly supported. MAXScript exposure is lacking to say the least.
Particle Flow has a more abstracted representation of particles as points in space that can contain all related data without depending on the mesh shape, although steps are being made to add interparticle mesh collisions in the future. It is VERY easy to set up quickly (IMVHO, one of the easiest particle system UIs to use) and does most of the everyday things with less work, but when it comes to the heavy stuff, it lacks some abilities. It integrates great with Krakatoa (which is what matters for me personally ) and provides some caching out of the box, but the real deal is part of a 3rd party extension called PFlow Tools Box #3 which provides in addition to disk caching also low-level channel access via so-called Data Operators, very similar to the way TP works with data. The MAXScript exposure is phenomenal (see my signature). Although scripted operators are generally orders of magnitude slower, a slower solution is better than no solution at all, so this adds flexibility, but the event-based nature of the system is more rigid than the rule-based concept of TP.
I find myself using PFlow a lot more for everyday's tasks, but there are effects we couldn't have done without TP (at least in the time allocated). For a starter in the field of particles, PFlow is easier accessible (since it ships with Max) and easier to master since the learning curve is less steep.
But in the end it is your choice - it is possible that your brain is better wired for the one than the other...
--------------------------------------------
It is an elusive thing to describe, but...
Let's see how the system interfaces with you:
In PFlow, you create particles that flow through containers (events), hence the name "Particle FLOW". The events are shown as nodes, inside these events (containers) the particles sit around and get their properties changed by operators and these properties get tested by Tests and if they return true, the particles move to another container. The Particle View shows you this flow, and you can see the particles moving from event to event if you enable the Count Display.
In Thinking Particles, you create the containers (groups) in a separate area of the UI and these groups are NOT shown as a flow. Particles can be sent to these groups at any time but you don't get an overview of where particles flow. What you see is a hierarchy of Dynamic Sets which are similar to Particle Flow Operators (esp. Data Ops in Box #3). Inside the Dynamic Set, you get to tell it which particle group (container!) to operate on and it can then read, modify and test the properties of particles AND send particles to other groups based on the logic wired inside the Dynamic Set. What you are wiring out of basic nodes is not the flow of the particles between the containers, but the logic of the particle behavior, hence the name "THINKING Particles".
So in a way, Particle Flow with Box #3 is very similar to TP, but it still works in the framework of an Event-Driven system, so you can use it both ways. If you create a single event and write all the logic of your particle behavior in a Box #3 DataOperator, you would emulate rather closely the DEFAULT modus operandi of TP. Adding Box #2 would make the two systems VERY similar.
Thinking Particles can behave like an Event Driven System if you use simple Dynamic Sets that only set particle properties without much internal logic and use lots of Group operators to send particles around to get affected by different Dynamic Sets based on their current Group .
Things like "If particle A is faster than 100 send to another Event" are the bread and butter of PFlow, but more complex setups like "Change Particle Birth Rate Based On the Distance Of Objects A and B" require Script or Data Operators, while TP eats that for breakfast.
This is of course a complete simplification of the topic and TP has a lot of added flexibility due to the hierarchical nature of its Groups, but I hope it sheds some light...
那就讓我來開始吧!!!!!!! 跟他說的第一句一樣耶~~~
英文能力不好,亂翻請見諒~
===我是翻譯的分格線 =====================================================================
那就讓我來開始吧(指比較這二個軟體):pf跟tp是不同的。他們看起來好像是做一樣的事,但其實不然。所以在工作流程中要決定用那一套,會依據你想要做的事,哪一個做的比較好來決定。
如同你已提到的,你的問題非常類似於"我該用max還是maya,為什麼?"
所以你得到的答案也會非常類似:"max對於你想做的事,有90%的部份是非常容易就達到的,但是對於其他的10%比較難做的,max就少了那麼點工具的著墨 ;
maya 少了一開始應該要很簡單的10%,但是maya把其他的部份,包含比較難的部份,弄的很簡單。你把上述的max改成pf,maya改成tp,那你就有了概念。
你在c4d中已經接觸過tp1了,在max裡tp是版本3,而且還發展。對切學者而言,它相當的強大但也相對複雜。對於須要把控制的物件分成不同的部份、內部的相互碰撞、任何須要模型之間的碰撞和在創作出高品質作品的過程中彈性的控制分子流程判斷式都非常的棒。tp傾向於把分子的資料當成是mesh的一部份,儲存在mesh中。所以要用大量的分子製作抽象的造形就可行。
舉個例:要整合tp跟Krakatoa就相當的不易。tp已經有了一套相當良好的封裝流程和內部資料以便日後再重新使用的系統(Black Boxes),快取的部份也相當的棒,直接支援了baking to scene objects(我不了解這個部份,無法白話翻譯),頂多只能說他在用MAXScript控制這一塊還有缺失。
pf相對於tp來說,雖然未來有一個階段是要加入內部分子模型的碰撞偵測,但pf更抽離於表示分子是空間中的一個包含所有相關資料的點而不依賴於mesh shape( x…我在翻什麼,我看不懂這一段中文,但是英文我懂…)。
pf非常容易就可以設定好(有個最容易用的分子系統ui),可以更有效率的完成日常工作。但如果遇上了比較進階的情況,它就是少了那麼些能耐…
它跟Krakatoa有非常好的整合度(我個人對這部份相當的重視…),提供了高於標準的快取,但其實真實的情況是我們用了box3所提供的磁碟快取還有對於更低階的資料存取…就是人家說的 data operators,這已經跟tp的處理資料方式相當的接近了。對於maxscript的支援更是傑出到不行(請看我的簽名檔…)。
雖然 scripted operators 一般認為他相當的慢,但是有一個慢的解決方法總是比沒有辦法來的好,起碼增加了彈性。
不過 以事件為基礎的系統,是比tp以規則為基觀念的系統來的"硬"一些 (我個人認為他指的是使用上彈性沒tp好)
我發現我自已在日常工作中用pf比較多,但也有的效特是沒了tp我們沒辦法完成的(在一定的時間允許下)
對於進入分子領域的初學者,pf很容易就能取得(啊就內建在max裡啊),而且很容物就可以學成出師,它的學習曲線沒那麼斜…
But in the end it is your choice - it is possible that your brain is better wired for the one than the other...
總的來說,這是你的決定 - 誰知道你的大腦跟哪一套比較合的來…
這不太好解釋,不過…
讓我們來看看分子系統是怎麼把資料經過秀給你的
在pf中,你會經建立流通在"分子容器"(在介面上就是event事件)的分子,所以才叫"Particle FLOW"。
event 被當成一個node秀出來,在events(分子容器)分子待在裡頭,分子的屬性經由操作子來改變並且分子的屬性會被測試操作子所測試,如果測的值為真,就會被傳送下一個分子容器中。Particle View會秀出這個過程給你看,如果你把Count Display打開你可以看到分子由這個event"流"到另一個event。
在tp中,你會在另一個區塊中的ui中建立分子容器 (group),tp中不會秀出分子的流向,你在tp中也沒有對一個分子流向的概觀,分子可以在任何時間傳送到分子容器。你所能看到的就是階層關係的 Dynamic Sets,有點像是pf中的操作子(特別像是box3中的data操作子)。
在 Dynamic Sets中,你必須告知它,要操作的分子容器是哪一個之後他才能讀、修改、測試分子的屬性,並且依照你在 Dynamic Sets的設定的羅輯判斷來分送分子到其他的分子容器中。所以你對其基礎的node所連操作的不是分子跟分子容器之間的流向關係,而是分子的行為羅輯,這也是他叫"THINKING Particles"的原因
在某個程度上,box3跟tp是非常相似的,但是box3還是在事件驅動這個框架下作業,所以你可以在二種方式之間作業。如果你只建立了一個單獨的event,然後利用box3的data 操作子,把所有的羅輯用data操作子實作。那其實就跟tp的預設工作模式差不了多少,再加個box2之後,這二個系統之間就更接近了。
TP也可以搞的跟事件驅式的分子系統一樣,如果你只用了簡單的Dynamic Set、利用他們來設定分子的屬性並且沒有用到太底層的羅輯運算,然後基於對目前GROUP、利用不同的Dynamic Sets來影響、操作、分流你的分子到不的GROUP中。
如果有個情況是"如果分子A的度快於100 ,那請把他送到另一個分子容器中",那麼這對pf來說非常的容易,再複雜一點的像是"請基於物體A跟物體B的距離來改變分子的出生率",對PF而且就須要用到SCRIPT或是DATA操作子,但是對TP而言就像是吃早餐一般的容易。
當然這是把這個對了二個分子系統比較的部份簡化了,而且tp在他原來的group設計中就有非常好的彈性,我希望我的解說對你有幫助~
=== 翻完了XD ============================
24 marzo
有人拿到…
有個朋友因為某種原因拿到了max 2009。對我們這種跟max有很深的革命情感的人(從dos版的r4用到現在),一定是非常希望能在第一時間內就知道max2009的新功能。
所以我迫不急待的問他有啥新功能,他說他也是剛拿到,才剛安裝完,目前知道的是max的預設render改成mr了。再來是視埠上多了像maya那個可以切換viewer的正方體,還多了一個圓形的ui,有點像是zbrush裡控制stencil的那個介面。也是寫著 front,left…等等的viewpoet的名字。
目前所知的就只有這3點…希望他今天上線之後我還可以再問到新東西…
目前的感想…
好像還是早早準備換另一套軟體好…( xsi 我來了…)
跟之前的版本一樣,換了個大改版…這次還提高了價格喔~
但是新增加的功能少的可憐…就目前所知道的這三個改變,第一個…不過是預設改成mr…第二、三個也只是花俏的東西。感受不到一個應該是從2008變成2009版該有的提升…(上個版本也是這個樣子…冏)
我拿max主要是拿來做人物動畫…但是這幾版的max在這改面的改進真是少的哭爸的可憐…
06 octubre
嗯…上一季的主題現在才開始寫,有點晚…還望大家原諒。
火焰專案我所制作的內容是小丑熊放火燒小綿羊總長度是300frame、10秒。
製作過程比較花時間的部份主要是動作的編排、如小丑熊的進場動作、出場動作以及它會如何讓小綿羊燒起來。最後決定讓小丑熊以空翻進場,用火柴來把小綿羊"惹火",再怏速的逃離現場。小綿羊就簡單多了,它只要站著吃草、被燒…就好了。
在火焰的製作方面當然是以FumeFX為主。被燒的是小綿羊,對於火燄的表現,我想營造一種比較卡通式的火焰動態。由下往上、從著火到熄火很迅速來造成某種不實際的,誇張一點的喜感。不過實際用了FumeFX之後。發現很難去控製他燃燒的速度,也或許是我還抓不到怎麼組合出讓火燄可以很快速燒完的參數設定吧…這是我在製作上遇到的問題之一。
因為小綿羊的身體、頭、手腳是分開的,又有key,要拿來當分子的發射器有點麻煩,所以我製作了一個替代的橢圓體來當分子的發射器。為了造成快速燃燒的效果,我用了動態貼圖,讓分子依照圖來發射,接著再讓FumeFX來模擬分子的流體動態,再把分子當成FumeFX的火源。
我還有製作一層fire dust來加強,就是火燄燃燒時會出現的灰。(感謝Aomay大大提供的建議)
火柴的模擬就簡單多了,就只是把火柴頭直接拿來模擬而已。然後把格子開的細一點,加上一點點耐心和一點點浪費生命…
就完成了火柴這一部份的火燄模擬了。
小綿羊的表情是在flash中畫的動畫,輸出成連續圖檔做成動態貼圖
color
mask
後製再合上背景、調調色彩、疊上AO、火燄…就差不多了。(合成layout)
背景的部份,一開始是用單圖片(如上圖),但是在合成之後被建議還是用心的做一個好一點的背景會比較好(有看過的二個評審一致認為 = = a ),但是這支動畫的製程已經拖太久,我不想再把時間花在這支動畫上面了,接下要還要開始趕工第三集,所以背景的部份就以單色調為主嚕。
後製用到的層
各層大圖(以frame258為主)
Beauty
color
ao
burned mask
fire dust
fire light
fire match
fire(sheep body)
final comp
這次製作有遇到了困難也得到了一些心得,寫出來跟大家分享
心得之一…上傳圖的最大寬為 735 px…每次試完都忘記,然後下次po圖就要再試一次…所以po出來的圖的大小都不太一樣… orz
心得之二…一季做一支小動畫好像還是不太夠,時間太短了…冏
其他比較不重要的心得…
想要在fumefx的rendering頁標裡對fire或smoke用fluid mapping,那就要在simulation時把simulation頁標裡最下面的simuate fluid mapping打個勾
想用fumefx來控製分子的運動的話,除了在pf中加個fumefx flow operator 之外,還要在fumefx的general頁標中的export channels加入velocity才會有用
除了音樂音效之外,大致上的製作流程就是以上所述的了。
雖然有很多缺點,但是我不會再對這隻動畫做更動了。接下來要準備下次要分享的東西,也要再製作變形金剛專案,也真的沒時間了再花在這隻動畫上了。
看看大家看完之後有啥想知道的地方,我再補上來~
不發火
02 julio
這個問題我也問自已很久了…houdini怎麼freeze object…現在我找到解答啦~~~如下 (出自odforce的Stevenong)
I think you're thinking in terms of other packages. You don't freeze SOPs in Houdini, you
lock them.

Select the last SOP you want Houdini to process till then click on the Lock icon, it will turn yellow. Basically, Houdini cooks all the SOPs before & stores all the computed data/info into it.
Here's the best thing: If you want to change something before the locked SOP, you just unlock the SOP, make your changes & then lock it again. That's Houdini for ya!

However, if you really you want to get rid of all the SOPs before a selected SOP, you can do it in the viewport. Make sure you're in Edit Operation mode instead of View only mode. Viewer Controls button(Down Arrow at top left of viewport) -> Edit Current Operation. Or hit 'Enter' in the viewport.
Now, navigate to the selected SOP in the viewport or turn on the SOP's Display(blue) flag before going to the viewport. Right-Mouse-Hold in the Viewport on the geometry to get the pop-up.
From the pop-up, select 'Delete History'. You'll notice all the SOP before the selected will be deleted & it will also be locked. Be careful with this though, you can't get the deleted SOPs back after you save.
The 'Delete History' will be the equivalent of XSI's "Freeze Modelling Relation' or Maya's "Freeze Construction History".
Then again, why would you want to do that in Houdini?

If you find there are too many SOPs to manage, Right-Mouse-Hold on the selected SOP & select 'Hide Inputs'. Voila! A nice neat network pane.

There are other ways to manage the SOP network but I'll leave that till the next time.
25 mayo
最近啊…突然對二套3d軟體很感很感興趣。其實也不能算突然,我沒什麼才能,就是平常愛玩點3D軟體。
所以常常東摸西摸摸一些有的沒有的3d軟體(這個不是好習慣…請大家不要學啊…)
扯遠了,這二套軟體一是Houidi,一是Blender。
對houdini感興趣是因為軟體架構良好,讓人傾心。
而blender…這個不用錢的果汁機…在2.43版時居然變的令人驚豔!
像時下流行的ao、normal map base lighting、sss(2.44 RC版才有)、composer、sculpt、這些不該有的都有了… = ="
像我max用那麼久了,說不羡慕其他的3d軟體,一定是騙人的。倒也不是說max本身有多爛多爛…cgtalk上一堆高手用max做出來的成品已經證明,作品作的不好有時後是人的問題,不是軟體的問題。只是…總是有些自已很想要的功能,但是max一直就是沒做進軟體裡。我自已很喜歡整合在3d軟體裡的composer,像 xsi 的 fxtree 我就很希望max有這樣的功能。
雖然這些東西用後製軟體可以做的更好,但是有時後殺雞實在不用用到牛刀。簡單的cut,沒有很特殊的特效,如果有內建d composer,也就不一定要用到後製軟體吧~
所以我現在自學houdini,自已想想都覺得可笑。用了一個軟體那麼多年了,卻又開始要從頭習慣一個"已經很熟悉的流程但整個不一樣的製作思考方法"。
或許你也會問…為何選houdini這個軟體來拆磨自已?為何不選xsi或是maya…
maya跟xsi做得出來的東西,我不覺得max做不到,沒必要花寶貴時間再去學可以做同樣事情的工具。houdini這個3d軟體有著不同的思維方式,令我有點著迷。houdini有很完整的動畫製作、後製模組…我不打算寫很多他的優點…因為我還駕馭不了,所以我現在寫出來的優點,對現在正在學習的我而言實是缺點…所以…或許我真的是沒由來的喜歡它吧…
感興趣的另一個blender,原因簡單,因為他不用錢。功能也不比付費的軟體差。我對blender還沒有很了解,我第一次看到他的介面時就很喜歡,可以自由的整調縮放,很自由。這樣子設計的介面不知道在自定動畫參數那一方面是不是跟max一樣的不方便不實用。(澄清一下,max不是不強,只是不好用。只是要練到把自定義參數用好,須要用到maxscript,我覺得實在不夠簡便)
它2.5改版的重點就是著重在介面上喔~
或許有興趣的朋友可以注意他的下一版,我想改進過的介面會容易上手的。(說到這裡就想到…houdini 9 也要改進介面喔~ 呵呵。)
我會把我學houdini的過程po在這一篇,或許不會常常更新。
我把學習houdini的過程當作是一種興趣,沒打算要拿他來工作的,就像釣魚,打電動一樣,不會給我自已太大的壓力的。
好像還沒寫到houdini的介面厚…真的打了太多的廢話了… = ="
那就從下次開始寫吧~ ˇ_ˇa
09 febrero
不會裝 zbrush的plugin嗎?
基本上其他的外掛裝法跟zmapper是一樣喔~~~
圖片順序由左而右、由上而下