Re: [Plib-users] Plib, OpenGL and particle engines

[Steve B. <sjb...@ai...>]

Risto S Varanka wrote:
 
> Has anybody implemented a particle engine (for fires, explosions,
> smoke, etc.) using Plib? I am trying to make one using ssgVtxTable
> as a particle, but I haven't got too far yet.

I wrote a really simple one for spraying water in an (unpublished)
game based on connecting up pipework.

> As there are examples of particle engines available for OpenGL, I
> started thinking if it would make sense to use raw OpenGL and Plib
> side-by-side for your application. I assume this kind of approach
> could lead to various problems, unless you are pretty sure about
> what you are doing?

Well, you can always derive a class object from ssgLeaf and write
your own 'draw_geometry' function that does whatever OpenGL calls
are needed.

In 'plumber3d' (working title), I was using GL_POINTS as the particles,
so I had a single ssgVTable (this is older code - written while ssgVTable
was still 'trendy') with ALL of the water droplets in it.  This used
100% SSG code - no raw OpenGL.

Since I only animated the positions of the droplets (not colour, texture,
normal, etc), all I had to do was iterate down the array updating the
coordinates of the points.

The biggest problem is updating the bounding sphere so that the droplets
are culled when none of them are in the field of view.

In the case of my game, I expected all the droplets to be in view
pretty much all of the time - so I just gave the ssgVTable an insanely
large bounding sphere and didn't worry about it.

Anyway, I had ~4000 water droplets spurting out of each of two or three
hoses - and still saw reasonable frame rates on Voodoo-2/266MHzAMD.
All I was doing was accellerating them due to gravity - and detecting
when *either* their Z coordinate fell below ground level or they passed
through a small 3D cuboid that was 'catching' them. (At which point they
either lost a point or gained a point and were then teleported back to
the 'outlet' nozzle).  The hardest thing was setting their initial
velocities and positions such that they didn't all fly out in a solid
mass.

> What should I do to the ssgNormalArray and ssgTexCoordArray?

Just leave them un-set. (Don't call setNormals/setTexCoords at all - don't forget
to explicitly disable lighting and texturing in the ssgSimpleState).  If all your
particles are the same colour, only set *one* colour for the entire leaf node...
that saves quite a bit of time.

That's exactly what I do in plumber3d - and it worked out nicely.

Hmmm - maybe I should dump plumber3d into the PLIB examples directory sometime.

It started life as an attempt at a 'puzzle' game - but it's not currently
puzzling.  :-)   I have all the mechanisms to draw a crazy network of pipes
that you can create with simple keystrokes while water is pumped into one
end and spurts out of the other.  The original idea was that you'd have
to route the water around obstacles to connect it up to a predetermined
outlet before you lost too much water....all in 3D of course.

Once you've done that once or twice, it's kinda boring though...does anyone
have any idea how to turn it into an actual game?  I was originally thinking
of just making it be a 3D version of one of those classic old 2D plumbing
games (Xpipeman is one that you see on Linux for example).

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net