Effex 2.0 release (also a PLE Version)


Whats going on these days :slight_smile:
Everybody is releasing / announcing new updates. Great !

I am glad to see a PLE Version for the new Effex 2.0 Fluid / Gas simulation tool. Wow :
http://www.dpit2.de/navie/index.php check it out. It looks very promising. I need vacation :wink:


Great! Congrats on public release! :beer: Gone testing trial version =)


effex 2.0 trial crash C4D at startup
I even tried the version with KrakatoaSR

I’m using R14 on OSX 10.7.5


Samir, thanks!

I had error with krakatoa version(one function not found), i forgot to update to to thinkbox team).

Most of Effex things(which i study) work at windows platform.


Hmm, we cannot confirm such a crash. But if you send me the bug report C4D creates, we may be able to figure out what is causing the crash for you. I would be highly interested to see it, try to reproduce it and provide a fix if possible.

Did you make sure it is Effex that crashed? Did the message say so? Coudl you try to remove all other plugins temporarily and see if it then still crashes (that makes sure it’s Effex…or rules it out).



Yeah, thinkbox changed a function name in their API, so the latest KrakatoaSR version is required! :slight_smile:

Anyway, OSX and Win should work just the same.


I gave the demo a spin last night and thought everything was going well, until I watched your tutorials and saw that the computational speed of liquid simulations at your end was calculating about 5-10x faster compared to my machine.

The default CPU threads are set to 0. Implying all cpu’s as you mentioned in the tutorial.
However this is very slow to compute at my end. In fact CPU threads set to just 1 provides a dramatic speed up over using all of my 16 cores (32threads). As I increase the threads, the slower it becomes. When I monitor C4D’s cpu usage, it reads as it should. 0 is using around 80% of my processor capability. 1 is running around 5%.

I’m running a 3.1ghz dual 8 core system.
Running on the latest version of R14.
Freshly reformatted just last night, hoping to remedy this issue.
Double checked installation instructions. Tried both standard Demo and Demo with krakatoa.

Any ideas what could have gone wrong? I’d very much like to familiarize myself with this workflow before a project comes up in September.


You’re definitely on to something. I have the registered version and an i7 with 6 physical cores (12 with HT). I ran the basic liquid scene in the viewport up to frame 50 and got the following times with various thread settings:

0 - 31s
1 - 57
2 - 34
3 - 26
4 - 23
5 - 23
6 - 24
7 - 25
8 - 26
9 - 27

Can see how that’s going … up to 31s for all cores. So in my case the sweet spot is four/five cores, which is about 35% faster than using all cores.

Tried it with the variable density liquid preset and it was even more pronounced. Four cores about 80% faster than all cores.

Just tested again using the smoke presets, where changing the cpu core setting breaks everything. Doesn’t render at all, even after setting the cores back to 0.


Thanks for confirming.
I’ve just performed a similar test with 90 frames and a simple liquid setup…
In my case, the difference is very dramatic.

0 (All) = 58 second
1 (single thread) = 17 seconds
2 ([color=DarkSlateBlue]a whole core?[/color]) = 22 seconds
16 = 49 seconds
32 = 58 seconds



the answer is simple in this case. 

Re/starting x threads (in your case 16 or even 32) probably takes longer than calculating the individual task. Meaning that at low resolutions (low cell counts as in the default scenes) you do not benefit from so many threads, but a lower thread count is more advantageous here. That's exactly why this setting is there, so you can tweak performance sometimes instead of Effex naively running all threads.

So intuitively you actually did the exact right thing. :slight_smile:

You will benefit from more cpu threads the more each cpu has to do, so higher resolution will benefit from more cores much more!

Probably I can tweak some more performance out of the threading in the future but this really requires some alone time as it’s not just a sideline.


Hmm, I cannot confirm any issues here that reflect that but there is something off with some parts of the R14 version on osx we noticed. A new version will be available soon taking care of some issues though.

I would be very interested in knowing if you still see this issue then. I think on monday.



I’ll recheck it, but I’m on Windows.


I’m sure I’ve read someplace that Multi-threaded particle sims often don’t scale up quite as well as you would think.

What I don’t understand however, is why when I copied what you were doing (in the tutorial), action for action. How come my simulation performed dramatically slower than yours when I set it to run? Your fluids were gushing out in almost real time, where as mine were really dragging their feet. Had you perhaps optimized the thread count yourself to something other than 0?

I honestly have a feeling that something else is wrong. Can but try on another machine to confirm.


Adam: Thanks!

I have quite an old i7 model with only 4 cores. So it adapts better (not as many threads) and my CPU does not run through the tasks as hell. I highly assume your CPUs are way newer than mine. So if you adapt the thread count you should get the same performance as I do (if not faster).

Let me know if that works for you. Thx!


I’m tryin the PLE as we speak but I must say I’m a bit worried at the moment.

While I like the concept of modularity, just like X-particles or Mograph, so far I feel the process has been pushed a bit over the top.

Control is good, but so far I’m curious to know why to create a simple emitter you need up to five or six objects linked together : Particles Grid Emitter + Particle Emisison Settings + Duration + Rate + alignment + particle groups…

Why not have one object with 5 tabs for such common settings with basic settings already dialed in?

I’m eagerly waiting for more documentation and tutorials, because as of now I find it a bit puzzling to say the least.


You only need two objects in that case.
The Particle Grid Emitter and the particle emission settings.

Duration, Rate (which only makes sense with a Particle Mesh Emitter) and alignment are all optional for further control.

Alignement for example is used when emitting vorticity particles only (so you can give them an initial spin direction).

Particle Group…well, you need a particle group to store particles. No way around this. And the emitter needs to know the target particle group (just as in TP).

The reason is the same as in a node based system (that’s how it’s internally structured), reusability. Just as you do in Xpresso to control several other nodes with a single one.

For example using a pmesh emitter with a pgrid emitter allows reusing durations, alignments and rates for both emitters and only changing one emission settings. This concept therefore gets more advantageous with complexity. In simple setups it seems over the top but with more complex setups the framework actually shines.

Why not have one object with 5 tabs for such common settings with basic settings already dialed in?

Because it destroys the advantage of in-depth modular control approach and it makes reusability impossible or only possible with hard-coded (even if dynamic) code. Also it makes extenting from the outside (other developers for example) way harder. And the new framework makes developement easier too (bug finding and fixes, faster updates, extensions…).

One has to keep in mind that the framework is not specific. It only provides an time and space integrated environment for any kind of stuff. The user could calculate orange growth using available structures or incorporate own algorithms or even extent the existing ones! Empowering this is only possible if deep access is given and that’s what the framework has in mind.

I’m eagerly waiting for more documentation and tutorials, because as of now I find it a bit puzzling to say the least.

Yeah, no doubt in the beginning you have to get your head around it (also because there are so many nodes) but once you get the hang of it you’ll see it becomes quite simple and powerful.

Please feel free to post any questions in our forum or here, we will gladly help. Also it’s good to check out the example files. But yep, tutorials and docs will follow definetly! We are urging promised :slight_smile:


Samir, is there a chance you could make the PLE work with the free student version?


I don’t think so I’m afraid because the PLE requires a serial number.


It looks shocking at first but if you keep at it you’ll find that you start throwing nodes around like it’s second nature, and that’s when the fun begins.


Looking forward to this but with the dearth of documentation/tutorials at the moment it’s hard to get into it. One thing it is not is intuitive.