When hunting down glitches, the debugger is the coder’s weapon of choice…

In the last post about coding advanced Python plugins, this vital part was skipped as Cinema 4D’s Python interpreter doesn’t support it.

But fear not – you don’t have to write countless ‘prints’ or fiddle with python’s inspect module just to fix a simple fence post error.

Stepping through breakpoints and browsing your plugins scope… – all this is possible with the PyDev remote debugger.

How does it work?

The PyDev remote debugger consists of a server running in Eclipse, listening to a given port – and a client (your plugin), that inspects the scope at runtime and sends it to the server.
This concept has the advantage of working with virtually any host-application one can think of – including Cinema4D.

The only disadvantages are that you have to add the client module to your source and to insert a small line of code for each breakpoint.

Setup

As the remote debugger comes with PyDev, it’s already installed within your IDE – we just have to find out where exactly as the installation path varies with the PyDev version:

• Browse to your Eclipse folder and do a search for a file “pydevd.py”

You should end up with a Path somewhat similar to this:
‘C:\Program Files\eclipse\plugins\org.python.pydev.debug_2.0.0.2011040403\pysrc’

If you find more than one ‘pydevd.py’, make sure you selected the PyDev folder with the latest version number within ‘plugins’.

• Now open the source file you wish to debug and insert:

  import sys
  sys.path.append('C:\Program Files\eclipse\plugins\org.python.pydev.debug_2.0.0.2011040403\pysrc')
  import pydevd

And that’s it!

Debugging

Let’s do a quick test run and place a breakpoint.

• Add the line pydevd.settrace() somewhere within your source
• Switch Eclipse to “Debug View” (upper right) or click ‘Window’ -> ‘Open Perspective’ -> ‘Other’ -> ‘Debug’
• Start the PyDev remote debug server by clicking the Icon on the top left (the small green bug with the blue ‘P’)
• Fire up Cinema 4D and switch back to Eclipse

You can now continue or step to other breakpoints by using the small icon bar on the top left or the F5-8 shortcuts.

The variable tab on the right allows you to inspect your plugins scope in detail.

In case this doesn’t work, check your firewall settings first before repeating these steps or taking a look at the PyDev documentation.


Tip:
Route the standard- and error output-channels to the PyDev console with…

pydevd.settrace(True, True)

With the debugging feature added, our Python plugin coding environment should now be complete…

Time to spring into action!

It’s been a long time… how have you been?

This is going to be another Python/Cinema 4D related post.

While python is great for quickly scripting workflow optimizing tools, prototype stuff or write generators and tags, is it suited for big, complex plugin development?

It is!

You get ‘nearly’ full access to the C++ API of Cinema 4D, don’t have to compile or worry much about platform dependencies, can easily find a ton of neat recipes and libraries out there…

So it’s not only possible to code full-fledged python plugins but it even has its advantages over classical C++ development.

Imagine you wrote a nifty script, decided to make it a simple plugin, and now want to take it a step further – add more features, a complex GUI with some dialogs etc…

If you are still working with the script editor by now, things will most likely start to get out of hand as you introduce more modules and classes, deal with more code and more functionality.

This is the point where you might want to look out for a little help.

We are going to set up an IDE (Integrated Development Environment), talk a bit about modules/packages and finally I will try to give some general hints and tips.

Coding Environment/IDE:

Prepare Cinema 4D:

You may skip this part, but I highly recommend it:

• Make a copy of your Cinema 4D installation – name it “Cinema 4D R12 Dev” for example.
• Get rid of all Cinema 4D plugins you don’t need for your development
• Place an empty text file named “c4d_debug.txt” into the root folder of your Cinema 4D copy.

This will slow Cinema 4D down a bit, but enables you to monitor memory leaks.

We will add some useful things on Cinema 4D-side later – for now let’s continue with the Eclipse setup…

Eclipse:

If you never used one, think of an IDE as your workshop, it’s a collection of tools as well as the place where you do and organize your coding work.

Eclipse is one of the most popular – its Java based, open source, free to use and most importantly has excellent support for python.

So let’s start by downloading and installing Eclipse Classic from http://www.eclipse.org/downloads/
If you don’t have the Java Runtime Environment installed jet, you need to do this first.

PyDev:

As said before, Eclipse has excellent python support – but not out of the box, so we are going to install PyDev.

PyDev will help you coding by adding syntax highlighting, code completion and much more.
Should you encounter any trouble with the following steps, please refer to the PyDev installation manual.

• After installation, startup Eclipse, click “Help”, and chose “Install New Software…”.
• Next click the “Add…” button, type in “PyDev” as name and “http://pydev.org/updates” as location – then confirm.
• Now enter “PyDev” in the “Work with:” field, you should see an entry “PyDev for Eclipse” - check it and click “Next”.

After confirming again and accepting the terms, it will download and install.

• Click “Windows” and open the “Preferences” dialog.
• Select PyDev and the child “Interpreter – Python”
• Click “New…”, input “Python Cinema 4D” as name and browse to your Cinema 4D installation.
• In “/resource/modules/python/res/Python.win64.framework/” select the python.exe.
• Confirm your selection and the paths PyDev wants to add to your syspath.

So much for the PyDev installation itself, now we have to associate the Cinema 4D Python plugin extension *.pyp with PyDev to enable syntax highlighting and code completion for those files as well:

• Open ‘Window’ within the file-menu and click ‘Preferences’
• Select ‘General’ -> ‘Content Types’ from the list on the left.
• In the ‘Content types:’ view on the right, unfold ‘Text’ and click ‘Python File’
• Hit the ‘Add…’ button of the ‘File associations:’ list on the lower right, type “*.pyp” into the popup and confirm.

Its helpful to add a file containing all symbols of the Cinema 4D Python API’s “c4d” package to the ‘site-packages folder to spice up the auto-completion – grab it here.

Place the file within “/resource/modules/python/res/Python.win64.framework/Lib/site-packages“

Note:

You will have to update this file if you want to keep up to date with future versions of Cinema4D, it can be easily printed to the console by executing:

for itm in dir(c4d):
    s = getattr(c4d, itm)
    print "%s = %s" % (itm, s)

Project setup

We take your IDE for a spin and create the first project:

• Click “File” – “New” and chose “PyDev Project”
• Input a Name for your Project and uncheck the “Use default” box below.
• Browse to your Cinema 4D installations plugin folder, create a new directory with your plugins name and select it.
• Select “2.6″ from the “Grammar Version”- dropdown and leave the Interpreter set to default.
• Last but not least uncheck the “Create default ‘src’ folder…” checkbox and hit “Finish”.

To setup the needed folder structure, header- resource- and string files for your plugin, please read the Cinema 4D Python documentation “Plugin structure” –  especially “Directory structure” – and take a look at the Python plugin examples within the documentation – or the experimental plugin from this post:

Just remember this part is vital, so do not rush through it – at least read the section mentioned above and take a good look at the SDK examples.

Only if you have built C++ plugins before and are already familiar with the structure, you may…

Hint:

You can also add your existing project files by just placing them within the plugin-directory we just created, or dragging them into the project-folder within Eclipse.

When organizing the file structure within your project, you are working with your file system – changes you do here are reflected on your harddisk.
This also works the other way round, move something on the file system and Eclipse will update those changes to your project – while not always instantly.

You can press F5 within Eclipse to update a folder and its subfolders or the contents of a file.

Don’t worry, if the project-view is out of sync with the file system – Eclipse will tell you.

A coders Cinema 4D:

We are all set with the IDE part – let’s tune the Cinema 4D installation a bit more to improve the workflow and finalize your coding environment.

If you didn’t add/import your existing code to the project we just created, write a simple hello world and fire up Cinema.

It’s a good idea to setup a developer friendly layout, I like adding the console window to the tabs on the right, next to the object manager – or even better to a side monitor.
Should you be writing a CommandData Plugin, consider opening the Command Manager and dragging its icon into the layout, so you can quickly re-open it.

You will be launching and closing Cinema 4D a lot during development – it’s helpful to have a strategy to quickly start and close it.
Place a link to Cinema 4D on your taskbar/dock, close it using ALT+F4/Command+Q or create a little python script containing “exit()” and add it to the layout/create a shortcut.

Finally, open your Plugin as well as everything you need to test its functionality and save the layout as startup layout.

If you have a test document that you need to check your plugin, press CTRL+E, click the “Open Preferences Folder…” button and place it as “default.c4d” within that folder so it will load on startup.

You long got the idea – try to prepare everything so you don’t have to spend time doing recurring tasks on every unit-test you are going to make during development.

Some additional tools:

It’s often helpful to keep an eye on memory consumption and or active threads so I always have the task manager/activity monitor in reach when coding.

And while not really necessary, it’s convenient to have a good, fast text editor with Python syntax highlighting so you are able to read a file or snippet without having to launch the IDE first.
I can recommend Notepad++ and TextMate or Emacs for this job.

Working with eclipse:

Eclipse in combination with PyDev is a mighty! tool – Aside from the obvious killer features – syntax highlighting and code completion, there is a ton of others.

Often you will discover some that will make you feel bad for not having used them right from the start, so I’ll try to point out the most useful, while I encourage you to read up on Eclipse and PyDev.

The Find/Replace Dialog

Press CTRL+F for all your search and replace needs – just listing it to make you aware of the direction-, selection- and regex support.
If you haven’t used regular expressions jet, you should directly head over to Wikipedia - you won’t regret it.

Even more powerful is the…

Search Dialog

CTRL+H opens the global or project wide search – here you can also replace over all files.

Just keep in mind that the “PyDev Search” tab does only look within *.py files while the “File Search” tab by default searches over a *.* pattern.

Compare feature and history

Just select two files, right click and chose “Compare with” -> “Each other”.

You can also compare a file with an earlier state of itself by choosing “Local history”.

This is another huge plus of using an Eclipse – don’t worry anymore about changing huge sections of code or commenting it – just go ahead and delete it – you can always return to an earlier state using the “History”- tab.

But use this with care, as it’s possible to lose the history by moving or re-creating a project and it’s not infinite.

Tabbed views

You can drag a tab to one side of the code view until a small arrow appears – the tab will then snap to that side, splitting your view so you can work with multiple source files at the same time.

This is very useful when working with the header-, resource- or string files of your project as you can code on the left and copy ‘n paste ID’s from the right for example.

Coding python for Cinema 4D:

We have setup the coding environment – how about doing some programming now?

This will be a loose collection of tips that are all more or less Cinema 4D related, but mostly  good practice in general.

Modules and namespace:

First – this is OOP (Object Oriented Programming) and your project’s structure should reflect that.

In general, classes and modules are a good thing, it’s a far more common fault to have less abstraction than too much.

Packages/Modules are also the key to keep your code organized, manageable – AND reusable.

So if you are going to write something that you might want to use again later, consider spending the extra time to make it a bit more user/coder-friendly and build a class or module.

When working with python and modules you have to keep a close eye on naming and namespace, especially in context with the Cinema 4D SDK.

Be creative and use unique module names – this will keep things easier when you are using other modules – and you will – at least the ones from the Cinema 4D API.
Also be careful when importing from modules – it’s rarely a good idea to just import everything (from foo import *) – instead carefully select the members you really need and give everyone its own import line rather than stacking them with commas in one.

It’s often better to just import the module into your namespace and reference the members via module.foo – you don’t pollute your namespace and it’s more readable.

In any case you should avoid the API’s module AND member names like the plaque.

For example if you extend the GeDialog Class and have a method “def close(self):” – but make the slight mistake to call it as “Close()”, you might end up with a similar behavior but wonder for minutes while your dialog just closes without saving it’s settings first (or whatever “close()“ should have done).

I know for some this is basic stuff – many have their own patterns for this and that’s ok!

Whatever you do – be consistent and aware of your namespace.

Symbols:

As you need to keep track of the enums within the c4d_symbols.h, it is best to define every integer by yourself and not auto-enumerate them.

Then mirror those symbols to a *.py file called “ids.py” and be careful to update both should you change them or introduce new ones.

Instead of hardcoding ID’s, you should always use the symbol within the c4d-package.
Should you ever need to identify a symbol by it’s integer value (for example if you want to check for a certain flag that is returned) – this little script will help you out:

import c4d;
from c4d import gui; 

def main():
    wanted = gui.RenameDialog("ID to search for...")
    outp = ""

    for itm in dir(c4d):
        s = getattr(c4d, itm)
        if s == int(wanted):
            outp += "%s = %s\n" % (itm, s)

    gui.MessageDialog("Sorry - none found..." if outp == "" else outp)

if __name__=='__main__':
    main()

API calls / performance:

Don’t get me wrong – the Python API is blazing fast – so fast you often can’t tell the difference to C++ – but still, API calls take time.
When working with thousands of objects, this quickly adds up no matter how fast each individual call is.

Try to limit those calls in sections of your code, where you really need performance – look for ways to keep states within your own plugin logic rather than querying them form Cinema 4D whenever possible.

If you are looking for bottlenecks, be sure to check out cProfile – it’s great.

Prototyping:

Using an IDE doesn’t forbid you to use Cinema 4D’s script editor and console to quickly whip up and test something – you can even write and directly execute a simple test script within eclipse if you are working on parts of your plugin that don’t need the Cinema SDK (some kind of parser for example) and take advantage of the PyDev debugger.

Debugging:

The lack of a real debugger can be compensated by using the PyDev remote debugger, pythons inspect module and the logging package.

Remember that there is a limit to the amount of characters the Cinema 4D console can output for a single print command.

Also take a look at sys.exc_info()

Garbage Collection:

When introducing circular references you should use weak references to give the garbage collector a hand.

Compilation:

How about shipping your plugin as precompiled byte code?

This will make Cinema 4D start up faster – as the compilation of your plugin can be skipped, obfuse your source and still be platform interoperable.

Just copy your plugin, open the console/terminal and execute “python.exe -mcompileall C:\PathToMyPlugin” and delete all *.py files afterwards.

Note that this might not work in some cases, so be sure to test your plugins functionality again.

Platform dependency:

While Python is platform-independent, there are still some things to keep in mind.

Don’t use backslashes in paths but slashes – they are understood by windows AND mac OS.

You can also use platform.system() to determine on what OS your plugin runs on and import modules after a conditional check – for example:

if platform.system().lower() == "windows":

    import winsound
    winsound.PlaySound(os.path.join(os.path.dirname(__file__), "../res/snd", "DingSound.wav"),
winsound.SND_FILENAME)

GUI – Threading:

It’s the old story, if the GUI thread has to wait for your plugin, you lock up Cinema 4D – unacceptable for the user.

Doing time intensive stuff within your own threads is the simple solution to this, but keep in mind that you can’t have them call the GUI thread – instead use messages and the GeDialog’s SetTimer().

Resource reference:

Classes that use the “plugins” module need a reference to the plugins resource pointer.

This can be handled by importing those classes within the plugins *.pyp file and setting the class variable “__res__” or using a singleton (see below).

Singletons and invading Borgs:

This is something for the advanced developer – and kind of a hot topic too.

The use of globally accessible objects or ‘globals’ is often considered bad practice but also unavoidable in some cases (logger) and python even somewhat encourages it.

So if you know what you are doing and think about using a singleton, you might want to take a look at the “borg”-(anti)pattern – a monostate proxy with a twist.

class Borg:

__we_are_one = {}

    def __init__(self):       
    self.__dict__ = self.__we_are_one

Still alive

This was a lot of compressed stuff to digest, I know, but please do me the favor and don’t let any of this scare you off, it’s easier and more fun than you would expect.

I am sorry some topics where not covered in the depth they deserve -  it wasn’t easy to keep this a readable post rather than a book…

I hope this still was helpful to someone, if you have any questions, thoughts or would like me to write a more detailed post on a certain topic – let me know.

Maxon has just released the R12 version of Cinema 4D, which includes Python – so let’s dig into Python plugin development!

We are going to build a ray tracer… with Python! Watch a rendered video.

Update: All Python scripts in this blog have been updated to work with the R12.

Ok, I’m sorry – I should have come up with something more useful, but hey – it’s fun and it serves the purpose.
Also this is not really about raytracing basics, but coding Python plugins for Cinema 4D – the cake is a lie!
And while I am apologizing… I don’t do tutorial style posts that often, so please bear with me.

This is meant for coders coming from a C++ or Coffee background, so if you are already familiar with Python you might want to skip a few lines.

Please note that this is supposed to be a template for a rather complex Python plugin, so don’t feel discouraged if you had something simpler in mind – no problem – you can just write a full-fledged plugin using only one *.pyp file.

Preparations

It’s a good idea to start by deciding which plugin type is best suited – in this case I want to write a CommandData plugin that will be callable from the Python plugin menu and open a dialog to display the rendered output.

So first I create a folder 'SmartPray4D' within the 'plugins' directory of my Cinema 4D installation.
(SmartPray4D because “Smart Python based Ray tracer for Cinema 4D” was exactly one letter too long for my taste ).

Within that folder I then make two other directory’s: ‘res’ – which will hold all resource files the plugin will load, such as *.res-, *.str files and the plugin’s icon.
The other one is called ‘smartpray4dpackage’ and as the name suggest I am going to create a package here.

A package is really just a collection of Python modules – or better ‘sub modules’.
It’s mandatory to place an empty file named ‘__init__.py’ within a package folder. This tells Python to look for sub modules within that directory.

Go!

Now let’s get started – within the plugin directory I make a *.pyp file – the entry point which will register the plugin with Cinema 4D.

First I want to append my plugins directory to Python’s search path, so it may find the '__init__.py' within the ‘smartpray4dpackage’ folder and treat it as package.

folder = os.path.dirname(__file__)
if folder not in sys.path:
    sys.path.insert(0, folder)

As you can see from that statement, Python doesn’t use curly braces but indentation (4 spaces) to define code blocks and logical operators are spelled out.

Now I have access to my package and import a config file that will hold some constants and the MyCommandData class that I will register in the next step.

from smartpray4dpackage.config import PLUGIN_ID
from smartpray4dpackage.mycommanddata import MyCommandData

The registration itself is done within the __main__ block and is pretty straight forward.
Note how I load an TIF icon from the ‘res’ folder and the PLUGIN_ID which was imported from the config class – you need to apply for a unique plugin ID from Maxon so your plugin won’t interfere with others.

if __name__ == "__main__":
    icon = c4d.bitmaps.BaseBitmap()
    icon.InitWith(os.path.join(os.path.dirname(__file__), "res", "smartpray4d.tif"))
    c4d.plugins.RegisterCommandPlugin(PLUGIN_ID, "Smart Pray4D", 0, icon, "A crazy Python benchmark", MyCommandData())


The meat

Let’s take a look at the previously instantiated MyCommandData class.
There is a private object __dialog which will hold the dialog that is created once the CommandData plugin gets executed by the user.
It’s created within the overridden method Execute which Cinema 4D calls once the plugin gets selected. ReloadLayout also has to be defined so Cinema knows what to do when the dialog gets restored.
In this case it’s a simple matter of checking if there already is a dialog or if it needs to be created.

Now this is where the fun begins – lets head over to the ‘mydialog.py’.

This module has the familiar __init__ constructor in which three objects __userarea, __scene and __renderer get instantiated. Note the self-parameter – it is similar to the C++ pointer or the this reference in ECMA/Java and has to be the first parameter in every class method.

The mydialog module then overwrites the CreateLayout which… does exactly that, and creates a timer that will call the renderer, providing him with the scene to render and the userarea as target for its output.

#END:

I hope this gave you a first glimpse at Python plugin development for Cinema 4D as this short introduction will end here.

The renderer itself is a nice piece of work keim_at_Si originally wrote for Actionscript 3 and JavaScript.
I did some small changes, but really just ported it to Python and tried my best to abstract it a little.

Now where to go from here? It’s really up to you Checkout the sources and have a look at the Python SDK documentation – endless possibilities…

Hint:
You can render a sequence of images to the picture viewer and save it as video using ShowBitmap().


Last but not least you can download the source here – have fun coding!

There are those popular structures we all know and love because they simply look fascinating from every angle – like the Sierpinski triangle, the Pythagoras tree or the Menger sponge.
Generative geometry is one more proof that math is beautiful no matter how basic.

Recently I stumbled upon a new pattern that is also phenomenally simple but produces rather complex shapes – the “Binary Kite”.

I first saw it in Mikael Hvidtfeldt Christensen’s ‘Structure Synth‘ – an ingenious tool for exploration of generative 3D structures.

Basically it’s a 3D array of randomly black/white colored cubes that slightly scale(linear) and rotate(noise) per iteration on one axis.
What makes it look so interesting is that each items transformation matrix is subordinated to its predecessor on that axis.

Initially, I played around with the kite in Unity 3D but quickly discovered that it can´t be animated at high iterations.


So I fired up C4D and wrote a simple Py4D generator.

The results

I did end up with this gorgeous picture of a 30*30*500 cubes kite (5400000 polygons) (fullsize):

Here is a closeup from the same viewpoint (fullsize):

Last but not least I rendered this short animation of a 5*5*150 kite growing:

Want to render your own kite with even more cubes? Grab the scene file here.

Update: The file has been updated to work with the R12 version of Cinema 4D.

Hint:
Remember to uncheck “Optimize cache” in the Python Generator´s properties if you want to animate the parameters.

Conclusion

While Structure Synth is awesome, Cinema 4D and Py4D are a great way to visualize generated geometry too as Cinema’s render instances enable you to work with millions of objects.


Cheers

I haven´t written about Py4D for quite a while now…

In the meantime, Maxon has first announced a cooperation with – and now the acquisition of Sebastian Rath´s praised python implementation for Cinema4D.

So finally – Cinema4D meets Python!

Let´s celebrate with some cool experiments!

If you are new to this blog or Py4D – a short introduction:

Py4D enhances C4D with a standard Python interpreter that provides access to the C4D SDK and allows to easily code platform indepentent scripts and plugins that control or extend C4D.

Basicly the same as COFFEE, C4D´s own scripting language, but Py4D has two major advantages:

• It follows the C++ SDK more closely and implements it further than COFFEE does.
• It is a easy to pickup, widely known language with a huge community and tons of existing code and librarys.

While C4D is a mighty tool in itself, this powerful scripting interface enables the user to work with external data, automate processes or build his own tools.

Being more the C++ type when it comes to plugin development and C4D, I enjoy being able to solve small problems just by hacking a few lines of code into the script manager.
I also prototype most of my plugins in Py4D before I start developing in C++ – it´s just more convenient.
The step of compiling for every test takes much more time in the long run.

So here´s the meat:

Four simple examples how to have a good time with Py4D and some particles…

Everyone requires C4D R11.5, the Thinking Particles module and the actual version of Py4D.

Update: All files have been updated to work with the R12 version of Cinema 4D.

Py4D has been through some changes since the open beta started, so I took the time to update the scripts I published in the boids, and strange attractor posts and included them here.

Click the images for a preview.

1. Stars4Py4D

This is a Py4D port of the Sagan experiment I did in flash <- check out this link, it´s fun

A good and simple first step with particles - position vectors get parsed from a CVS database and from a galaxy of suns… “My God. It’s full of stars!”

Hint: this example might be the best to start with, as it includes comments – the others don´t, because they use pretty much the same pattern.

Just download the package, load the scene and change the path to the CSV file within the “file” user data field of the Py4D Tag.

2. Phy4D

A very simple adaptation of a 2D “physic engine” – works only with spheres.
The direction of gravitation is animated to make this a little more interesting.

Have a look at the preview video and scene file.

3. Boids

This is simply a revival of the Py4D Boids post – same beast, but updated to the Py4D release version.
The script creates a flocking boids swarm, that behaves according to the rules outlined by Craig Reynolds.

Checkout this video from Sebastian and get the scenefile.

4. Strange Attractor

Again just the script from the original strange attractor post, but ported to the final SDK.
View the final rendering and the original post – you can use the Strange Attractor Finder to locate your very own, chaotic attractor!

Here´s the scene file.

Conclusion

Python and Cinema4D are a great team and Py4D is THE alternative to COFFEE.

I hope this gives everybody who is interested in Py4D and controlling particles, a small head start, some inspiration or at least something fun to play with


Thanks to Sebastian for suggestions, support – and of course Py4D.

Cheers!

Strange attractors are fractals that emerge at certain, sensitive parameters within the three-or more dimensional phase space.

They are are researched since the early 70s and strongly related to the chaos theory as they allow to watch the transition from chaos to order/geometry.

Good things first: see the result and try the chaotic attractor finder!

The 3D visualization of a strange attractor is quite resource intensive as points race around the attractors on chaotic trajectories – so it needs many iterations or particles to see a shape emerge from that chaos.

There are already some great flash experiments so I turned to Cinema 4D and PY4D as an advanced renderer would easily allow to raytrace and shadow the results – and to calculate even more particles of course.

This small PY4D script creates a strange attractor that Dr. Clifford Pickover had published 1990.

I managed to render a maximum of 50.000 particles with the R11 on my machine.

But with the new R11.5 release Maxon introduced render instances to C4D allowing now to calculate up to millions of particles – depending on the system.

I went with a number of 300.000 points, seeded the attractor parameters and rendered four transparent animations that could be combined to a 1.2 million particle video.

The preparation time for each frame was ~1min while PY4D took less than a second of that duration to perform five sinus/cosinus operations for each point.
Rendering itself took about five seconds per frame (CPU:Q6600).

If you are interested you can download the szenefile here.
(Remember to activate render instances in the PShape node of the XPresso tag).

Update:
The scene file has been updated to the R12.

When I learned that you can actually identify strange attractors using the Lyapunov exponent and found John Holder´s programm ‘lyapdemo.c’, I took a few minutes to port it to AS3.

You can use it to generate parameters for the PY4D script.

Sebastian Rath´s PY4D is a new, alternative way to script with or to code plugins for Cinema4D – without COFFE or C++ – but in Python.

The current beta (v0.9.0001) already makes a fine impression and proves itself easy to get started with.

This video shows a little script that was adapted in a twinkling and controls the particles of a TP-Storm to behave after the three flocking boids rules.
Don has rendered a much prettyer version of the dummy above.

You can download the C4D-scene here.

Update: The file has been updated to work with the R12 version of Cinema 4D.