Multiple Particle Systems Emitting 3D Primitives
Hi,
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...
Hi Michael,
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.
best, Thijs
Hi,
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.
Thanks,
m
=============================
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.
-Thijs
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...
So I guess the question remains about using multiple displaylists...
-T
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.
thanks again,
m
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)
best,
wes
here's the patch:
thanks wes! that's really good to know.
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? ;-)
-Thijs
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.
Andrew B.