mathomp

I dont understand why I can not get Multiple Particle Systems Emitting 3D Primitives working in Jitter. I can not find any information in the Help (html or otherwise) that states how to do it. See code below... If I only connect one particle system, lets say the right one, it renders correctly. If I connect the left one it(left one) does not render the primitive but the right one still works. With the left one connected, if I disconnect the right one I get nothing until I save, close the patch and open it again then the left works correctly.

Here is a test patch borrowed from other posts in the forums with me adding the primitive stuff...

multiple-particle-systems-emitting-3d-primitives

You problem is not with the particle systems, but with ogl depth settings.

Right now you don't control the rendering order of the particle systems. Try

to set @depth_enable 0 for the primitives that are on top of each other. If

you do want to use depth, set @automatic 0 for all primitives and control

You problem is not with the particle systems, but with ogl depth settings.
Right now you don't control the rendering order of the particle systems. Try
to set @depth_enable 0 for the primitives that are on top of each other. If
you do want to use depth, set @automatic 0 for all primitives and control
the drawing order manually.

Thanks for the info. I still can't seem to get it to work. I have looked at some examples of controlling the rendering order. All of the examples look like my latest version that still doesnt work.

Any help or examples would be very helpful.

I discovered that if you only use 1 or no displaylists, it works fine. I've

never used them so I don't know why this is. Maybe there is only 1

displaylist buffer on a GPU? I doubt if displaylists are useful in this case

anyway, because all particles are moving all the time, and displaylist are

only going to increase performance if a lot of the drawing commands stay the

same. Updating lots of commands in a displaylist can even decrease

performance afaik. Here's the edited version.

I discovered that if you only use 1 or no displaylists, it works fine. I've
never used them so I don't know why this is. Maybe there is only 1
displaylist buffer on a GPU? I doubt if displaylists are useful in this case
anyway, because all particles are moving all the time, and displaylist are
only going to increase performance if a lot of the drawing commands stay the
same. Updating lots of commands in a displaylist can even decrease
performance afaik. Here's the edited version.

Displaylists do seem to make a huge performance difference after all. Only I

don't understand why my computer is having trouble with the patch running 1

system of 256 particles (displaylist on). I better start another thread on

So I guess the question remains about using multiple displaylists...

PS: a possible bug?: If I move the system away from position 0 0 0, I notice

flickering particles at position 0 0 0. (winxp, max 4.5.7, jitter1.5.2.)

Displaylists do seem to make a huge performance difference after all. Only I
don't understand why my computer is having trouble with the patch running 1
system of 256 particles (displaylist on). I better start another thread on
this. Don't want to hijack this one...

PS: a possible bug?: If I move the system away from position 0 0 0, I notice
flickering particles at position 0 0 0. (winxp, max 4.5.7, jitter1.5.2.)


Thanks a ton! I will continue to try to understand the jitter way for doing things. I wish the docs and tutorial had more details though.

Try this one. It uses jit.gl.mesh to render the matrixoutput of

jit.gl.gridshape. jit.gl.mesh uses a more efficient strategy to store

vertices on the graphics card and as a result is way more efficient

for multiple draws than gridshape. I doubled the number of objects

each particle system is generating to 50 in the patch. With

jit.gl.mesh it runs at 30fps and with jit.gl.gridshape it runs at

Hi guys,
Try this one.  It uses jit.gl.mesh to render the matrixoutput of
jit.gl.gridshape.  jit.gl.mesh uses a more efficient strategy to store
vertices on the graphics card and as a result is way more efficient
for multiple draws than gridshape.  I doubled the number of objects
each particle system is generating to 50 in the patch.  With
jit.gl.mesh it runs at 30fps and with jit.gl.gridshape it runs at
17fps. (on my PB 1.67)

but are you guys experiencing the same error? Moving a system to 0 0 -3 for

example and watch the center for flickering non-transformed black-colored

also the "emit" message doesn't work on my computer. it can only turn off

the particles at some negative value, but there's no difference between 0

although it's faster, I still have the feeling that a dedicated jitter

object can be far more efficient. I just watched a fireworks animation by a

friend who used just opengl in a little C app. It was capable of rendering

way more particles on his computer which doesn't even have a really fast

I read chapter 13.6 (particle systems) from the orange book, but I guess

that's going to be tricky to implement in a jitter external no? It sounds

perfect though, to have a shader based particle system. Maybe something for

a future release? Or do I just have to study a little harder? ;-)

but are you guys experiencing the same error? Moving a system to 0 0 -3 for
example and watch the center for flickering non-transformed black-colored
particles.

also the "emit" message doesn't work on my computer. it can only turn off
the particles at some negative value, but there's no difference between 0
and 200.

although it's faster, I still have the feeling that a dedicated jitter
object can be far more efficient. I just watched a fireworks animation by a
friend who used just opengl in a little C app. It was capable of rendering
way more particles on his computer which doesn't even have a really fast
gpu.

I read chapter 13.6 (particle systems) from the orange book, but I guess
that's going to be tricky to implement in a jitter external no? It sounds
perfect though, to have a shader based particle system. Maybe something for
a future release? Or do I just have to study a little harder? ;-)

We hope to offer a more efficient solution in a future version of 

Jitter. The bottleneck at the moment is the use of jit.iter to break 

With a little hard work and ingenuity, you could probably generate a 

shader-based particle system, but it will take a bit of work as shader 

programs have no memory and no buit-in RNG. For generating lots of 

particles, it may be more efficient to do all of this in Javascript, 

using jit.op/jit.expr to do the physics math. You may also buy some 

performance by using jit.gl.sketch to do the transform/render of your 

Regarding displaylists - they will give you a performance boost if you 

are rendering the same geometry multiple times, so they are ideal for 

use in this instance. Since you can't change individual aspects of a 

displaylist, it would decrease performance with geometry that changes 

often, as a new displaylist will be generated for each change.

Please look at the OpenGL red book for a more detailed discussion of the 

We hope to offer a more efficient solution in a future version of 
Jitter.  The bottleneck at the moment is the use of jit.iter to break 
the matrix up into max messages.

With a little hard work and ingenuity, you could probably generate a 
shader-based particle system, but it will take a bit of work as shader 
programs have no memory and no buit-in RNG.  For generating lots of 
particles, it may be more efficient to do all of this in Javascript, 
using jit.op/jit.expr to do the physics math.  You may also buy some 
performance by using jit.gl.sketch to do the transform/render of your 
particles.

Regarding displaylists - they will give you a performance boost if you 
are rendering the same geometry multiple times, so they are ideal for 
use in this instance.  Since you can't change individual aspects of a 
displaylist, it would decrease performance with geometry that changes 
often, as a new displaylist will be generated for each change.
Please look at the OpenGL red book for a more detailed discussion of the 
pros and cons of displaylists.