我翻了這二篇：
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裡啊)，而且很容物就可以學成出師，它的學習曲線沒那麼斜…
總的來說，這是你的決定 - 誰知道你的大腦跟哪一套比較合的來…
----第二段----------------------------------------------
這不太好解釋，不過…
讓我們來看看分子系統是怎麼把資料經過秀給你的
在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 ============================
