Best way for particle engine?

[Fool Running]

I've been playing around with different ways to create a particle engine in LWJGL and the best I've found is to create a Java array, create a direct buffer, do my calculations on the Java array, and then put the Java array into the direct buffer and give the direct buffer to LWJGL.

This (obviously) slows down the particle engine from all the memory transfers.

Is this the best (possibly only  :? ) way to do this, or is there another, faster way?

I can live with it this way, but I would like to have a little more speed.  :wink:

[Fool Running]

I've toyed with the idea of creating a C++ particle engine and using that, but I'm not a seasoned C++ programmer :oops:  and don't want to take that route.  :lol:

[princec]

The first way, calcs on Java objects and then blatting the results into a bytebuffer, is actually the fastest way to do it and is the same from C++. It's just lots easier in Java.

Cas

[Catharsis]

Check out the ARB_point_sprite extension. Found in LWJGL under ARBPointSprite and ARBPointParameters.

Presently, I have tried both working with NIO buffers and using glDrawRangeElements via vertex arrays and also creating a loop and calling glVertex3f for each point.. The loop won out with the overhead of filling the array and putting it in the NIO buffer, just by a little bit.. oddly enough.. I was sure the NIO buffer/VA/glDrawRangeElements would have been faster, but it wasn't..    I will try dynamic VBO soon, but hey.. point sprites are the way to go for a particle engine in OpenGL regardless..  I'm using it for bullet fire, explosions, sparks, and a bunch of other stuff in Auriga3D (www.auriga3d.org)...

[Fool Running]

Thanks guys for the info  :lol:  I'll have to try the point sprite thing  

[princec]

the only problem with point sprites is if you encounter drivers without them implemented you've got to go and bloody supply the whole code path for quads instead. Bah. That, and the fact that they blink out existence before they move offscreen.

Cas

[Catharsis]

the only problem with point sprites is if you encounter drivers without them implemented you've got to go and bloody supply the whole code path for quads instead. Bah. That, and the fact that they blink out existence before they move offscreen.
Cas

Yeah.. I am not sure if the last problem I am having with point sprites is actually with ATI drivers currently..  I've detailed the problem here.. http://www.auriga3d.org/problem/

The same problem occurs with LWJGL & JOGL.. and I don't think the code is wrong at this point...

I am using a Radeon 9700Pro (w/ 4.6 Catalyst), so if it doesn't work right with this card then it might not be the best route to take, but again it is darn fast and efficient compared to the quad route!

I'm not quite sure what you are describing with the "blink out of existence before they move offscreen" part though..

[cfmdobbie]

I'm not quite sure what you are describing with the "blink out of existence before they move offscreen" part though..

There are a number of OpenGL primitives that are anchored to a single point that if clipped will cause the entire primitive to be clipped.  It's really fast as the GL can avoid lengthy fragment generation before clipping, but causes the odd effect Cas describes where the point and thus the primitive is clipped when you'd expect part of it still to be visible.  I guess point sprites must fall into this category.

The same is true of bitmaps: if the point set by glRasterPos is clipped, the bitmap is not drawn - even if at least part of it should logically be visible.

[aldacron]

Yeah.. I am not sure if the last problem I am having with point sprites is actually with ATI drivers currently..  I've detailed the problem here.. http://www.auriga3d.org/problem/

There is a known issue with ATI drivers and point sprites. I can't recall if it was fixed in the latest driver release or not. You can find more info about it at the opengl.org forums.