Multiple Particle Systems Emitting 3D Primitives


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

    • 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
      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
      =============================
      max v2;
    • 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.
      -Thijs
    • 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...
      -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.)
    • 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 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:
    • 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? ;-)
      -Thijs
    • 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 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.