Skip to main content
gamedev.net
🔒 Locked

mult-function particle system

Started by SoaringTortoise Feb 27, 2003 at 7:19 AM 1 replies 350+ views
Original Post
SoaringTortoise
SoaringTortoise
Howdy, I''ve got a particle physics system running, and it works very well. As part of the particle system, I''ve allowed it to move meshes as well as billboards about, and to mix and match between billboards and meshes. Each particle can have a random assignment of particles, meshes and texturing, but will move according to the particle''s physics definition. This system allows me to create just about everything from smoke & sparks right up to flocking-seagulls and bouncing giblets (or, perhaps if I wish, flocking sparks, bouncing seagulls, gently rising wiffs of giblet and showers of smoke). However, I think that it could all be rendered in a far more optimum way. At present, I just depth-sort all the particles to be rendered this frame and render each one according to its type (mesh/billboard). The result looks fine, but is a bit sluggish with only a few thousand particles. I accept that I must loose performance on the mesh-particles due to their polygon count but how can I optimise the billboards (each of which may be differently textured, and orientated - either verticle or horizontal)? Or is it just a dream to have such a multi-functional system? Learning to fly is easy, but as a tortoise, the landings are really rough.
Always prey on the weak, the timid and the stupid. Otherwise you'll just get your butt kicked
For a tortoise, this is extremely hard to do, but when you get it right... the expression on their faces ...
SoaringTortoise
SoaringTortoise
I sort of know what I''m doing, but I''m facing a fairly interesting problem in that I''ve got billboards (with different orientation/texture/size) and more complex meshes all being driven by the same system so the normal optimisations don''t really apply. But now, I don''t know what will yield the best performance/visual benefits.

If I depth sort and batch-render the objects according to object type, then I can get into all kinds of alpha problems (particles showing as being on-top of semi-transparent meshes even though the mesh is closer to the camera), but if I don''t batch the objects by type and keep the perfect visual, are there other ways to optimise?

Using the one draw-call would be ideal if I only had single-texture and object types. Turning off the non-essential render options I haven''t done yet, but the benefit from that should be marginal (although worthy).

My problem is that although I can use different rendering paths, these are likely to look incredibly fragments from a desire to stop the alpha glitches (either on-top rendering from disabling writes to the a z-buffer, or rectangular holes from enabling writes). It could look something like this:

1) Render 2 Billboards
2) Render 1 Mesh
3) Render 1 other mesh
4) Render 18 Billboards
5) Render 1 Mesh
6) Render 89 Billboards
7)...

etc.

So... I''d probably get a performance benefit from the batching, but if the fragmentation is high, I''m going to take a serious penalty because of the extra processing creating the micro-batches.

I suppose I could stream the mesh data into the VB, instead of using the mesh render line, and then a large tiled texture so that I could use a single draw function (in which case the VB would contain billboard polygons as well as mesh polygons indescriminantly), but that sounds quite a lot like rocket-science to me (and possibly even slower given the need to lock meshes to copy their VB''s etc.... plus, how on earth would you handle mesh rotations under such a scheme?).

Learning to fly is easy, but as a tortoise, the landings are really rough.
Always prey on the weak, the timid and the stupid. Otherwise you'll just get your butt kicked
For a tortoise, this is extremely hard to do, but when you get it right... the expression on their faces ...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.