Particle Flow vs. Thniking Particles


#1

Yeah. Here is the question.
Which, and why ?

I’m a total starter to 3ds max, was using C4D for some years, so be gentle :buttrock:.


#2

Thats like me asking you max or maya.
Which, and why ?

No one can make your mind up for you, its up to you. pflow is max’s native particle system, and is an event based system. TP is developed by Cebas and is a rule based particle system. There are pros and cons for both and im sure no one would be able to tell you 100% which one to use.

Pflow is easyer to get your head around if your new to max and particles, there are quite a few pflow tuts online (www.allanmckay.com for example) and max ships with a few basic pflow tuts.

Personally id suggest looking into pflow before venturing into TP. TP is (currently) a bit more powerful (rigid bodies for example), but TP also sometimes takes a bit longer to set up, and is a bit more complicated untill you get used to it and understand how it works.

Hope some of that helps.


#3

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…


#4

Thank you for the great explanations !

I felt like I can adept myself easier to TP, but most people say that PFlow is better for starting out… Well, but I do ask myself, without mesh collusions… I dont know.

The following question comes in the PFlow side:
I do not know maxscript [which requires programming abilities as I saw] and I’m not thinking to learn it. I have seen one of the DVD’s in your link [PFlow scripting 1] and thet seemed like… everything is done with maxscript, which is not a thing I want to do.

So the next question follows:

Maxscrippt is a pre-request for both PFlow and TP ?


#5

Possibly the best articulated and least biased explanation I have heard on the subject Bobo :slight_smile: I would have to agree for sure!

Thanks
Michael McCarthy


#6

No there’s no prerequisites for pflow or tp - scripting is going to be more handy for pflow, especially if you don’t have box #3 - box 3 and tp both give you access to all the bits of data that the particles use so you don’t need to use scripting as much.

I’d agree with bobos post that pflow is far easier and quicker to get used to so if I’m doing a simple effect I’ll go for pflow every time. For heavier effects involving really high particle counts or anything to do with dynamics / fragmenting I’ll go for tp. I’d also say the caching system and overall performance in tp is better.

Both systems are very useful and it seems that autodesk has again brought in the original programmer of pflow so you should see more improvements in this for the coming versions of max.


#7

What exactly is Box3 ?
I searched autodesk site and it’s probobly explainy enough, but not for me.

I need dynamics, and particle interactions. With BOX3, can PFlow do this, or I still need tp ?


#8

I think both systems are great and anyone thinking of using particles should know both, in my humble opinion. What you can’t do with one you can do with the other. Of course I am only starting out using TP, and wow, you can find out for yourself there is a demo available HERE

Box #3 is available HERE

As for dynamics PFlow Tools Box#2 will be available in the near future, it is getting ready to come out of alpha and into beta. The dynamics system in box #2 is awesome and very easy to use see some of these simple examples:

SmokeStack + particles QT 36 mb

Strands.mov QT 34 mb

Plank N Pivot QT 10 mb

Rope Bridge QT 30mb

Anselms Tests


#9

Hey bobo, nice explain. :slight_smile:

Could you explain what is the “rule based” way that TP works? I know what is the event based, but since I never worked with TP I have no idea what could be ruled based.

Box #3 is a plugin sold by orbaz: http://www.orbaz.com/products/particleflow/box3/
But I think it doesn’t work with dynamics, you have to wait for box #2 to be released.


#10

I’m sure someone could explain this better than I but…the gist of it

Rules are exactly what they are, rules.

If particle A does this then do this.

If particle A hits particle B then create particle C.

You create your particles then predefine a set of parameters and when your particles test true or false to these actions they continue on (or they don’t and keep doing what they are doing) to the next set or group of rules.

So, in a sense it is like an event based system when you use tests to validate conditions. It is just with TP that you can get way more complex with the conditions, akin to using Box#3, nearly every bit of particle data is available to manipulate in one way or another.


#11

Thanks for the repply Johnny, I’ve read the explanation in cebas site but your comparision make things clear. This way we can think that particle flow with box #3 can be more advanced because we can merge events with rules right? On the other side, TP can have some sort of event or it’s all about rules?


#12

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…


#13

Sorry, I don’t mean to confuse.

Pflow is linear in fashion A->B->C->[test ‘true’ move on or test ‘false’ stay in C] and runs in a loop, it flows like water down a stream, along the way - test: collision with rock then splash - do something else, other water continue to the ocean, then evaporate, go up to a form a cloud, then rain filling the stream again.

TP everything resides in groups and dynamic sets.
So water is flowing down the stream,rule: water flows downhill, rule: if water hits rock splash, rule: if water reaches ocean evaporate, rule: if water evaprates create a cloud, rule: if there is a cloud rain.
‘A’ can go to ‘B’, ‘C’, or ‘D’ as long as it meets the conditions of the rules you set. It doesn’t have to start at ‘A’ then go to ‘B’ (like Pflow), it can go straight to ‘D’

Does that make better sense?


#14

Yes, thanks a lot Johhny and Bobo for taking your time writing down these explanations, now thing are much clearer to understand. I love to work with particles but I’m also alone with particle flow and box #1 from the subscription, so it’s good to understand how box #3 and TP works to know when it’s time to pay an extra bucks to get them and also to spend some hours learning new ways to work with particles. :wink:

Cheers!

Flávio


#15

Hehe… even in your example, you can in fact have a particle in pflow go to event B or C or D depending on what test a particle tested true for. It’s really a hard concept to explain, I think Bobo is as close as it’s gonna get. Really, I feel like it all comes down to conditional statements (if this then that)… but the difference in interface / flow of logic. On another note, I personally like the way Box3 handles object / geometry sampling… some incredibly helpful nodes in there. :smiley:


#16

^LOL, I prefer Bobo’s explanation too :), ya your right, I was trying to conceive it in the simplest possible way, but what goes in on my head is certainly harder to type :p:D. Even ‘if then else’ is very possible in both.


#17

Bobo’s pretty much covered it. I’ll say that I’ve been working mostly in Houdini for the last few years, but whenever I work in MAX I bounce between PFlow and TP. They are two very different systems with their own set of unique strengths and weaknesses, as has been mentioned. Generally I can do most things with PFlow, but anything involving fragmentation, dynamics or complex rules I use TP for. Both particle systems have their share of frustrations where something that should be simple just isn’t. PFlow was designed from the ground up to be a flexible, yet generalized particle system to make all types of users happy. For this reason it makes a lot of assumptions for you and limits your choices to fairly common ones for the sake of speed and simplicity. TP is a different beast entirely, focused more on capabilities at the expense of simplicity and generalization, making it more of a niche product. TP doesn’t make many assumptions and if anything it requires you to build a network of operations to do what may just require a single operator in PFlow. Of course, building that network allows you very high level access to the data and how it’s manipulated, ultimately giving you more control. So again, it’s a compexity vs simplicity argument.

With that said, there is room for both and I think any MAX artist who does primarily effects animation should consider having both in their toolkit.


#18

Here is my 2 cents worth on the original question. I’m an effects artist like Bobo and Brandon but I do a whole lot of production work and teaching. Something that I find happens a lot is I get artists coming to me asking me to write them plugins or scripts to add tools that they need. About 80% of the time those tools already exist in Max and they have just never bothered to learn the package that they are using. So I think that you should use PFlow first, not because it is better, faster or easier but because it is part of Max and you should understand the limits of Max before you start to add plugins to get jobs done that you could already do.


#19

Hey Brandon, thanks for sharing your knoledge with us and I also agree with PEN that we should first know the limits of max before going to plugins. Bobo’s tutorials are one of the great examples of things we can do with particle flow using scripts. Also Pete Draper www.xenomorphic.co.uk have some nice examples using plain max with no plugins.


#20

We use a couple of simple tests to determine if we should do a shot in TP or PF…

  1. “If/Then” effects are done in Pflow, “Until” and “For” effects are done in TP. (put a different way, if you need to solve, then TP).
  2. Anything involving Krakatoa is done in Pflow.
  3. Anything involving Maxscript is done in Pflow.
    3a) Anything involving the SDK is done in Pflow.
  4. Anything involving transforming an object (not particles) is usually done in TP.

Now the other requisite for comparing the two is to assume that with Pflow you have the complete Orbaz set AND that you have Krakatoa. Which is why we’re not asking about what kind of abstraction of data there is; or whether we’re dealing with collisions, pressure, or fragmentation; or how the caching is handled, etc.

While I agree that making presets is easier with TP, it’s never a make or break situation for us. We aren’t “wired” for thinking about assets as components, but rather as .max files anyway, something that is just a part of life with 3dsmax.

  • Chad