particles, OF/Processing VS Max6 ?

the jit.p.* objects don't do any collision detecting, except for p.bounds.

not sure if you can use multiple p.bounds, but should be easy enough to test.

best way to render points is to send the xyz matrix values to a jit.gl.mesh @draw_mode points

best object for flocking is the jit.boids3d 3rd party external.

Hi Rob and thanks a lot for your answer.

ok for collision detection, I had to write that, aesthetically speaking, I'd finally prefer to switch off collision detection (saving CPU a lot) and use dynamic & moving flocking target + attractors + repellers with dynamic changing forces.

Ok about jit.gl.mesh for GL_POINTS drawing.

Curiously, and now, I know openGL more by coding than by Jitter.

I'll let you know.
In the meantime, here are some snapshot (OF based but..)
I'd like to have this kind of rendering in jitter which is totally possible.
Here, 16k particles at 60fps. This is a target I want to reach in jitter.

I used the java version of boids3d so I could tweak it a little. I was happy with it to create flocking of birds....well...more like robotic fish with wings. ;-)

I didn't do flapping and gravity so the installation morphed into a Tron-esque forest having silver shaded low-res birds which would fly away from you unless you held up your hands. Then they would come eat the virtual food out of your hands until it was all gone. Attractors, repulse, Kinects, etc. were used, no real birds were harmed, but stacks of boids died. ;-)

I only used a few hundred birds; more became too Hitchcockian. The 3 simple flocking rules and their params in boids is very flexible and very important to tune so you get the behavior that you like. Everyone has their own artistic preference on how a flock looks and behaves.

Recently, I wrote GLSL code which renders a pointcloud of 307200 (640x480) vertices. It was trivial in Max to render with points, lines, tri, quads, etc. CPU and GPU were both under 15% (and a chuck of CPU was Kinect raw data processing).

My approach to several things like this has been to push as much as I can to the GPU. It allows me to use low power/cost CPUs (like the AMD Fusion which include a nice integrated GPU) to do distributed rendering/work. This allows more CPU time for Max's scheduler to do the things it is great for doing. Due to the nature of the Max scheduler w/ graphics, it tends to be single threaded so I have run into scenarios where overall my CPU is only 20% busy but Max can do no more work because it is only running on "one" of the CPU cores.

Geometry shaders enabled a lot of this. Sometime over the summer, I want to tackle GLSL tessellation if Max can support that program type because they are faster at massive vertex creation than geometry.

Can I create a Tessellator program in Max 6.1?
Julien, perhaps writing some particle work in OpenCL within a Max external? It could be cross-platform and cross-GPU. https://cycling74.com/forums/opencl-in-jitter-part-one-jit-cl-noise/

i made this particle patch a few months ago, little particles are floating in a forcefield, but you saw it Julien already...

Hit me up on FB and can send over the patch if it can be useful...

I made it with GEN, not using any of the own particle objects of max...

https://vimeo.com/61983077

Kevin

Hi Dale & Kevin and thanks for your interest & answers :)

Dale, ok, got it.
does the java boids stuff is available somewhere ? I mean, the library..
is it this one http://www.red3d.com/cwr/boids/index.html ?

I'm amazed by the collision detection system based on quadtree (2D only here. else: octree) I'm currently digging/testing in OF. 16k particles is very big.
For my performance / pieces, I'd need 8k. This work study is about global behaviors and I'd display each particle as a point only (maybe a point with a size of 2 with glEnable(GL_POINT_SIZE) enabled) but points.

Do you use collision detection ?
Maybe it isn't required and of course it would save calculation a lot.
Aesthetically, I have to test.

About attractors, finally, maybe moving flocking targets would be very enough. I mean, flocking handle the whole stuff.

I like a lot this : http://www.s373.net/code/boids/
There are boids behavior (flocking I mean), kind of deflector planes + attractors planes too etc.
A Max object seems to exist but is very old.

Kevin, of course I watched it and more than one time :)
I enjoyed the sound too. and your logo in the background adds this particular mystery we like !

Both,
are you using also vishnu and jit.p stuff ?
I don't know if, finally, there is a benefit in my case where, flocking, is required.
I mean, my whole system could be:
- particles (!)
- moving flocking targets & deflector to disturb a bit the quietness
- collisions or not

I'd like to have some groups of particles too (randomly choosen for instance)
I'd apply some forces only to on group, flocking to the other and changes etc.
Maybe, it would be too much complicated and aesthetically, multiple flocking target concept is very enough.

I have to check :)

Dale, about the openCL and GLSL stuff, I'm MORE than interested
Kevin, jit.gen stuff too (anyway it goes to GLSL too)

Yo Julien, here is the Flowfield attached... not perfect, only 2 dimension, but it was perfect for what i needed it for... maybe some tweek and you can use the object!
I can display 2-4000 spheres with this, so i guess 8000 points cant be a problem :)
You can add 1 attractor (if the force is negativ then it acts as repeller)...

...and the object outputs position matrix so you can use it in jit.gl.mesh or jit.gl.multiple depending on your needs. Use the maxhelp patch to test it!

to be honest it's so easy to do a jit.gen object to handle the particles the way you want, i had a feeling it's not worth to use wishnu or jit.p ... althought maybe that has some speed optimisation, but i think jit.gen can be pretty fast and if you handle the particle physics inside then you can do more complex movements than the built in objects...

Hi Kevin and big thanks
I'll check it today

We have some discussions with Dale about flocking, attractors etc.
Aesthetically, flocking seems a very nice way for me. Indeed, I can make things exploding or following one point by tweaking parameters.

I identified at least 4 big solutions:
- jit.boids3D (as suggested by Rob) is nice but I cannot do much more than 2000 particles and even at 1000 it gives sometimes 19fps which isn't enough. (curiously, even boids2D does this)
Probably, I can tweak it because we have the sources (provided by André Sier) and even the XCode project :O)

- java adapted from http://www.openprocessing.org/sketch/6910
Dale made a project with that as he explained above. I didn't test it, I'd have to port the processing code to "pure" java which doesn't seem that hard (doesn' seem..)
I'd need some deflectors, some attractors and ... check the next item

- boids library for Processing (and openframeworks) by André Sier (again!)
It works very fine. This could be the code I'd port to pure java for use in Max. Anyway, the code works fine with Openframeworks and that could be also the way to go for me.

- OpenCL
making boids using OpenCL seems ok (http://ruimadeira.wordpress.com/2009/10/30/openlcl-particles-test/)
that means using QC.
I found several stuff to use OpenCL in Max but it is (curiously) very processor (at least gpu) dependant and I didn't achieve to make it working here.
I still didn't test OpenCL addon in Openframeworks but the crazy guru Memo Atken made something working with 1M particles (!)
https://vimeo.com/7332496

Someone else did that:
https://vimeo.com/13349189
more chaos with 700k particles.

I still didn't choose but flocking would be my real aesthetic choice
That means the André's boids for openframeworks could be perfect but afraid of particles number.

OpenCL seems the way.
I'd just need to implement my boids stuff in openCL with the ofxOpenCL code.

André pointed me to this nice article:
http://www.research.scea.com/pscrowd/PSCrowdSandbox2006.pdf

and I wanted to show you Antoine's work too:

https://vimeo.com/49065256