Sign in to follow this  

Point Sprites -- Lock Buffer every frame?

This topic is 4588 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Technically for particles to move more realistically each should have its own buffer and its own matrix thus allowing it to move completly independant. This of course has a flaw since you may be working with 1000's of particles and 1000's of matrix transformations for a simple particle scene is to much. So instead I have decided to move the particles in object space and set one matrix for the entire particle scene. This method requires a lock of the buffer every frame to move the positions around which is costly. I do however think that it is much faster than seperate matrices for each particle. Em I on the right track?

Share this post


Link to post
Share on other sites
Yeah, sounds right to me - it worked fine for me when I did this!

As a couple of ideas if you do have problems:

1. Do all of your updates on your own system memory version of the data first; then lock the VB and do a memcopy or similar all-in-one-go copy of the data. That way the lock is held for the least amount of time, and you're not looping through the data reading/writing it.

2. Create/Lock the VB with the dynamic/discard flag (forget what it is exactly now!) and just write a new copy in each time. Might give you a bit of performance.

3. If you're wanting to be really clever... a couple of time-slicing ideas
- Don't update the particles every frame unless they're really fast moving. If you have a reasonably fluid frame rate (e.g. 50+) you can probably get away with updating every 2-3 frames.
- Don't necessarily update all the particles each time. Maybe if you have 2000 particles, only animate/update 1000 at a time. This might require additional VB's to work though...

Those last ones were something I meant to try out - a means by which to cut some corners were the end-user probably wouldn't notice [wink]

hth
Jack

Share this post


Link to post
Share on other sites
What I do is track clusters of particles that are created at the same time ( like a set of sparks from an explosion ).

I move each particle individually, and track the group's bounding box for culling.

I lock the dynamic vb once per cluster, write the particles in, then unlock and draw that part of the vb.

I typically only have ~20 clusters on the screen at once, so this works well...

Share this post


Link to post
Share on other sites
Quote:
Original post by SimmerD
I typically only have ~20 clusters on the screen at once, so this works well...

I don't suppose you would happen to have a screenshot or two lying around, would you? I am interested to see what you are working on...

Share this post


Link to post
Share on other sites
Quote:
Original post by Moe
Quote:
Original post by SimmerD
I typically only have ~20 clusters on the screen at once, so this works well...

I don't suppose you would happen to have a screenshot or two lying around, would you? I am interested to see what you are working on...


[lol] SimmerD > us. Simple fact - he's one of the mathemagicians over at Nvidia. He knows things we don't [sad].

Quote:
What I do is track clusters of particles that are created at the same time ( like a set of sparks from an explosion ).

Clever... so you'd have some sort of time based grouping... that if you had 1000 (for example) particles emitted per second, that you might group them together? thus, over 5-10 seconds you'd end up with 5-10 of similarly related groups?

Quote:
I lock the dynamic vb once per cluster, write the particles in, then unlock and draw that part of the vb.

Presumably this is similar to what I mentioned in my post with regards to simulating on the CPU and then "dropping" as much data onto the GPU in one go as possible.

Quote:
I typically only have ~20 clusters on the screen at once, so this works well...

Care to share any numbers on how many particles per cluster you deal with?

Some time back I tried to experiment with this, but I was more interested in some ray traced shadowing effect (it looked sooooooo amazing) but my combination was more of a per-frame division (see original post) than a "per-time" division.

Cheers,
Jack

Share this post


Link to post
Share on other sites
Well I started with a few important aspects.
First off, a buffer being created with D3DUSAGE_DYAMIC and D3DPOOL_DEFAULT apparently is important according to microsoft and performance. D3DUSAGE_WRITEONLY has to be used as well or Debug mode gives warnings.

Now, simply rendering 100 point sprites in one place on top of each other cause's my milliseconds per frame to go from 2.2 to 9.0... Why?!?!

Share this post


Link to post
Share on other sites
I batch the particles... into one large group and render all at once this generally increases speed like hell. Also if the particles are far from the camera I decrease the number of particles rendered by using the distance forumla this cuts down lag on objects further away seeing as you cant see them very well why render all the particles? [smile]

Share this post


Link to post
Share on other sites
I have many plans for optimizing the particle systems for my engine.
But right now my biggest concern in the massive jump in fps.
Going from 2.2ms/frame to 9.0ms/frame just because I'm rendering 100 particles to the screen.... Or is this a normal jump?

Share this post


Link to post
Share on other sites
This is a normal jump as you render objects to the screen the FPS moves in an exponentinal sort of way. If im correct the jumps are larger when the fps is high and they slowly get smaller.

So I feel its rather normal, other things to consider are the design patterns of how the particle system is setup. I have a very good setup on mine so I don't see much difference

Another huge thing to consider if your having major FPS jump issues is to create a frustum culling system and only render the stuff seen by the camera; not things off screen this generally increases the FPS massively if its not already implemented.

Most game engines infact use this process and I belive its one of the key ways of increasing speed, besides a few other techniques.

Share this post


Link to post
Share on other sites
Quote:
Original post by Moe
Quote:
Original post by SimmerD
I typically only have ~20 clusters on the screen at once, so this works well...

I don't suppose you would happen to have a screenshot or two lying around, would you? I am interested to see what you are working on...


I'll see if I can put together a screenshot or two later on tonight.

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Clever... so you'd have some sort of time based grouping... that if you had 1000 (for example) particles emitted per second, that you might group them together? thus, over 5-10 seconds you'd end up with 5-10 of similarly related groups?

- For some particles that recycle, like a fountain, the same 100 particles would just recycle over time. For other things, like debris or sparks from explosions, all particles created at the same time are in the same cluster, and are killed at the same time, although I sometimes make some invisible early - like if a splash lands in the water, it becomes disabled. So, I really try to manage the whole cluster as a group.

- For instance, if the an explosion happens offscreen, there is no cluster created, and if a cluster's bbox goes offscreen, and it has a timeout, I kill it early.

Quote:
Quote:
I lock the dynamic vb once per cluster, write the particles in, then unlock and draw that part of the vb.

Presumably this is similar to what I mentioned in my post with regards to simulating on the CPU and then "dropping" as much data onto the GPU in one go as possible.

- yep.

Edited by Coder: Fixed post. It was b0rked, for some reason, with SimmerD's reply inside quotes

[Edited by - Coder on May 25, 2005 11:35:48 PM]

Share this post


Link to post
Share on other sites

This topic is 4588 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this