Coldplay / Fix You When you try your best but you don't succeed When you get what you want but not what you need When you feel so tired but you can't sleep Stuck in reverse
And the tears come streaming down your face When you lose something you can't replace When you love someone but it goes to waste Could it be worse?
Lights will guide you home And ignite your bones And I will try to fix you And high up above or down below When you're too in love to let it go But if you never try you'll never know Just what you're worth
Lights will guide you home And ignite your bones And I will try to fix you Tears stream down on your face When you lose something you cannot replace Tears stream down on your face And I...
Tears stream down on your face I promise you, I will learn from my mistakes Tears stream down on your face And I...
Lights will guide you home And ignite your bones And I will try to fix you.
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... 總的來說，這是你的決定 - 誰知道你的大腦跟哪一套比較合的來…
import wx class MainWindow(wx.Frame): """simpyly deruve a new class of Frame""" def __init__(self,parent,id,title): wx.Frame.__init__(self,parent,id,title,size =(200,100)) self.control = wx.TextCtrl(self,1,style = wx.TE_MULTILINE) self.Show(True)
import wx class MainWindow(wx.Frame): """simpyly deruve a new class of Frame""" def __init__(self,parent,id,title): wx.Frame.__init__(self,parent,id,title,size =(200,100)) self.control = wx.TextCtrl(self,1,style = wx.TE_MULTILINE) self.Show(True)
而說到PLE版，最重要的當然就是有什麼限製啦！ The only limitations in PFTrack 4.1 PLE are the ability to export camera and image data. Projects created in PFTrack 4.1 cannot be opened in the retail version, limiting PFTrack 4.1 PLE to non-commercial use. 嗯…不能輸出攝影機跟影像的資訊，果然都是俺了最重要的部份啊~ 酸歸酸~但是人家有放出PLE版算的上是很有心的~
Herramientas 
)
