particles, OF/Processing VS Max6 ?
Jun 10, 2013 at 2:41pm
particles, OF/Processing VS Max6 ?
I just tested some personal extrapolation of Kyle Mac Donald’s quadtree implementation in Openframworks (for 2D) and also Memo’s MSAPhysics (3D)
Here is a cheap/light stuff with some moving repellers and ome attractors too.
Now, jit.p.x family.
I’m very interested by your opinions & experiences here.
I’m trying to build my system for my A/V performance and I’d need flocking, circular movements
Jun 10, 2013 at 4:30pm
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.
Jun 11, 2013 at 1:01am
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.
Jun 11, 2013 at 4:02am
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 (640×480) 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?
Jun 11, 2013 at 4:45am
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…
Jun 11, 2013 at 7:11am
Hi Dale & Kevin and thanks for your interest & answers :)
Dale, ok, got it.
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.
Do you use collision detection ?
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/
Kevin, of course I watched it and more than one time :)
I’d like to have some groups of particles too (randomly choosen for instance)
I have to check :)
Jun 11, 2013 at 7:12am
Dale, about the openCL and GLSL stuff, I’m MORE than interested
Jun 11, 2013 at 4:24pm
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!
…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…
Jun 11, 2013 at 11:43pm
Hi Kevin and big thanks
We have some discussions with Dale about flocking, attractors etc.
I identified at least 4 big solutions:
- java adapted from http://www.openprocessing.org/sketch/6910
- boids library for Processing (and openframeworks) by André Sier (again!)
Someone else did that:
more chaos with 700k particles.
I still didn’t choose but flocking would be my real aesthetic choice
OpenCL seems the way.
Jun 12, 2013 at 2:33am
André pointed me to this nice article:
and I wanted to show you Antoine’s work too:
Apr 16, 2014 at 6:45pm
Could somebody elaborate more on detecting collisions in a different way than using the collisions detection of jit.phys.word? With this latest, the computer is choking a lot when there is more than 400 particles…
Apr 17, 2014 at 1:34am
Some of the reading that I have done suggests collision detection with large numbers of objects is somewhat the “nearest neighbor” problem. There are storage mechanisms like R-trees which can help reduce the number of objects that you need to check for such collisions.
Apr 17, 2014 at 1:35am
glsl seems to be the way to process data in the fastest way.
I had to use some Barnes Hut implementation and I can go until around 500k particules on the CPU without any problem at 60fps with collision detection and energy conservation (elastic collision)
Quadtree binning is also a nice way :)
Apr 17, 2014 at 1:43am
(diablodale is fucking fast, he always answers (just) before me!)
You must be logged in to reply to this topic.