Multiple Particle Systems Emitting 3D Primitives

    Apr 27 2006 | 4:35 am
    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...

    • Apr 27 2006 | 8:51 am
      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
    • Apr 28 2006 | 3:06 am
      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
    • Apr 28 2006 | 9:51 am
      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.
    • Apr 28 2006 | 10:39 am
      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...
      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.)
    • Apr 28 2006 | 2:08 pm
      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
    • Apr 28 2006 | 4:05 pm
      Hi guys, Try this one. It uses to render the matrixoutput of 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 it runs at 30fps and with it runs at 17fps. (on my PB 1.67)
      best, wes
      here's the patch:
    • Apr 28 2006 | 5:30 pm
      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? ;-)
    • Apr 28 2006 | 6:03 pm
      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 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.