Point Sprites -- Lock Buffer every frame?
Author
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?
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
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
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...
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...
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...
Quote:Original post by MoeQuote: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
Author
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?!?!
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?!?!
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]
Author
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?
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?
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.
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.
Quote:Original post by MoeQuote: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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement