Advanced particle system: Test 1
Blitz3D Forums/Blitz3D Programming/Advanced particle system: Test 1
| ||
| http://www26.brinkster.com/bed1/FSPS.RAR This is a prototype of the advanced particle system I'm working on. If some people could test and post their framerates, I would appreciate it! |
| ||
| memory access violation... |
| ||
| Might be nice if you didn 't surround the link in *'s so that it shows up as a clickable link. :-) |
| ||
| Even with the clickable link you'll have to copy and paste, sorry bout that. Mem access violation. I'll have to see about that! [EDIT] Heres the fixed file. http://www26.brinkster.com/bed1/FSPS.RAR |
| ||
| Looks very nice, only that the FPS seems messed. It varies from 50-75. |
| ||
| I got FPS from 102 - 110 |
| ||
| I get around 112 on my lowly AMD 1800 with gforce4 MX. |
| ||
| It varies from about 145 to 158... |
| ||
| Why do people insist on using RARs? I don't bother downloading RARs and I think a lot of other people don't either. |
| ||
| Yeah, i don't have Win Rar either. |
| ||
| Varies from 60 to 80. P3/1G, 256MB, ge4ti4400, WinXP Pro |
| ||
| I get about 150FPS Pentium 4 @ 2GHZ Radeon 9600 Pro |
| ||
| Outch! 240 fps |
| ||
| 144 to 173 GeForce 4 mmx (really a GeForce 2) Doggie |
| ||
| I'll start using winzip in the future, didnt mean to be problematic m8s! |
| ||
| 160-170 |
| ||
| Why not just make self extracting rars? Sorry didnt mean to get off topic.... */Me retreats back to his cave* |
| ||
| theres no source code! :o\ |
| ||
| RAR has a much better compression ratio and (WinRAR at least) supports zip & rar compression in one package. |
| ||
| theres no source code! :o\ what makes you think there should be? duhhhhh65-75 here |
| ||
| 83 - 115 fps Athlon 1.4 Ghz GeForce4 Mx 440 Is this single surfaced? |
| ||
| RAR has a much better compression ratio. No it doesn't. It's better at some, worse at others. An example I zipped up was 1075KB for ZIP and 1029B for RAR. Hardly much better. The executable in the RAR was compressed more but the .png files in the ZIP were compressed more. If I had included more .png files, the RAR woould have been the larger file. Depends on what you compress. |
| ||
| Then the best way is to try both ways, which is what I think 7zip does. 7 ways to compress=better ratio. The only problem is not everyone can open um yet ;(. |
| ||
| Yes it's single surface. I have to add particle rotation then the basics will be complete. |
| ||
| I get around 112 on my lowly AMD 1800 with gforce4 MX. 'lowly'? |
| ||
| For a single surface system it seems slow. In the demo you had only 100 particles, and my athlon 1800xp and Radeon 9600pro gave only about 120fps? |
| ||
| The demo had 1000 particles. It will probably see a speed increase when I add the option of how often to update the particles facing. |
| ||
| okey then :) |
| ||
| Not sure how I will handle mesh particles... Needs to be single surface but manipulating large numbers of vertices could really hit the speed hard. |
| ||
| Hmmm... seems a tad slow indeed runs at around 80-100 fps here, I can recreate the demo with my own single surface particle system and it runs at 260 fps, using 2000 particles which are larger then those in this demo and running at a higher resolution. |
| ||
| Hmmmm, curious, I wonder what I'm doing to cause that. [Edit] I squeezwed more speed from my system by not using pivots as controlers, but still I only get 80 FPS with 2000 particles. What are you doing in your system retro? |
| ||
| I've decided I don't believe you retro, since after removing almost all the activity that my system was using, and no texturing(I'm assuming you are using alpha blending like I was) I still only get ~120 FPS with my system. Please prove me wrong though so we can all know how your managing it! Nice work if you can honestly hack that though dude! |
| ||
| Sure shattered, I'll post a quick demo of my system this afternoon :) (in a few hours if lucky) Mind you I've been using single surface particle systems since well forever, way before vertex alpha was even around. (though it has realy started to shine since that feature was added, before I had to use a hybrid system to make things work) I'm guessing you just need alot of optimalization. Edit: might take abit longer, since I don't have access to any webspace atm, will have to call in a favour. :P But expect it today in anycase. |
| ||
| Great, thanks. I've got a new demo here for everyone to test. Should be alot faster! Could you post your system specs retro? I do have alot of optimisations to do indeed. http://www26.brinkster.com/bed1/FSPS.zip |
| ||
| athlon 1.4 GHZ, GF2 GTS, 512 mb ram (SD), to be replaced within a week... :P New one seems to run at 80 FPS here, but the particles are bigger yet non blended, so I'm guessing there was a small preformance gain. |
| ||
| Other then alpha blending, there is no blending, aye. So ya don't want to give any pointers I take it? :) I'm optimising alot, but don't seem to be getting the massiv speed gains you are... how are you managing your sprite realignment with the camera? |
| ||
| Well I can't realy go all open on this seeing how the particle system I'm using is part of a blitz extension framework I've been working on for some time now, it replaces and/or enhances a LOT of blitz's functionalities. The quadpool system used by the built in particle system is just one of those things. The blitz terrain for example has been completely replaced in the BlitzX framework and where it once was there is now a multi LOD terrain system capable of handling and generating infinite terrains with far better detail and preformance then those originaly used in blitz, these terrains can be generated with incredible ease (using a special tool included in the package) and use a splatting method for texturing the terrain, so no matter what the size no texture detail is lost. Asside from that the terrain can be modified in realtime to support for such radical things as total climate changes. I am concidering releasing several demo's of this system shortly however it is far from sure if this system will ever be up for sale as it is beeing used to develop a rather sizeable game and I'm not very fond of the idea of releasing the very base of our outdoor engine. Ofcourse massive intrest might cause my thoughts on that subject to change. |
| ||
| the trick is to re-use and not use clearsurface and rebuild. |
| ||
| That's one important thing indeed, but I think everyone is aware of that, that's 1/3rd preformance gain right there, if you weren't doing that already that is. |
| ||
| I am re-using the quads. |
| ||
| are you effectively culling the quads? are you skipping calculations for non-visible quads? |
| ||
| Doesn't matter, right now all quads are visible. I'm getting 219 FPS with 1000 particles onscreen... Though I still want to up that.. How the hell is he doing it?!?! I'm happy with the almost 70 FPS increase but still, must continue. |
| ||
| Had to call in a favour for the hosting so don't mind the slow speeds. This demo uses 2000 single surface particles, which are all moving and onscreen, to show you that it all works you can look around and move using the mouse. Don't forget to hit space to get a real fps reading, 2d text can take a bite out of the fps. www.darkattackforce.com/user/gaianova/quaddemo.zip Enjoy, Retro |
| ||
| Very nice, would you mind posting you framecounting code? I dunno if mine is accurate. |
| ||
| mine is very simple, tho part of it is integrated in my timing module, you can recreate it by doing this every main loop: fps = fps + 1 time = MilliSecs() If time > oldtime oldtime = time + 1000 totalfps = fps fps = 0 EndIf |
| ||
| How are you rotating your quads? TForm or sin and cos method? |
| ||
| Very impressive Retro Booster :) That's some speeds you are getting there!! |
| ||
| TForm. I've upped the speed on my particle system to match Mr. Retro's now, but seeing as he's made such a nice demo, I'll wait till I've finished uo my system to show anything more! :). |
| ||
| Mmmm, i tried optimising mine. Updating the particles once ever 6 frames. I get 800 particles, alphablended, using entityblend mode 3 and alpha effects, at 467 fps. That's the highest i can get i think. |
| ||
| I think you just update it every so often. Updating every frame slows the system down. |
| ||
| I was reading this thread and got curious of how fast a particle system run.... so I decided to write my own. And I noticed that the slowest part is when the model has to be sent back in the gfx card, After even one vertex is modified. So even doing this doesn't run as fast as for example the thing posted by retro: for i=1 to 2000 for p=1 to 4 vertexcoords surf,vert,0,0,0 next next ;THATS 2000 PARTICLES AND 4 VERTICES EACH MODIFIED PRE FRAME So getting fps like RETRO was getting is imposible, IF you update every frame. And IF you don't update every frame, then the FPS doesn't matter. Hell, I can get 1000 FPS by updating every fourth frame. So, please post a demos that update every frame so there's something to compare. |
| ||
| I propose doing it in batches. There is a clear limit, probably defined by agp 4x for most people :) |
| ||
| You mean like updating 500 particles per frame for example? I don't think that will help much. My framerate took the same hit when updating 1 vertice or updating 1000 vertices on my radeon 9600. So I think the whole mesh has to be updated on the gfxcard anyway, whether you update 1 or 1000 vertices. |
| ||
| One question... Has anybody come up with solution for that damn z-ordering problem when using alpha? The particles could be z-ordered manually, but I suspect it would be too slow to be of any use in a particle system with thousands of particles. |
| ||
| Yeah, if you're updating every fourth frame or something, then you're not giving a true FPS reading. You're also not giving a true FPS reading if all the particles aren't visible at once. Here's why. I get 640fps with your demo Retro. Now, the particles look like they're moving very smoothly. And they are. Because even if you update every fourth frame, you're still updating them at 100fps. But now put them into a game where the other graphics slow the game down to 70fps. Updating every fourth frame, you'll now have particles that only move at 17fps, and the dicontinuity of the two framerates will look awful. Even if you only moved them every other frame, the particles would look choppy compared to everything else. Now even my shadow system cheats a bit to get the speed up, but what I do is have the system dynamically change the rate at which it updates based on how much a particular shadow is changing. So that way the shadows will never look choppy. If the framerate drops, then the shadow maps will be updated every frame. If it rises the shadow maps might be updated every four frames. And that's okay, because it'll always look smooth. As for a particle system, it doesn't work like my shadow example because in reality I update the shadow meshes every frame, but what I'm talking about above is the shadow textures. I can't update the meshes every few frames. But with particles, what you could do is determine how much the particle rotates in a particular frame, and how far it moves. Then you create an "epsilon" value for both, and if either episolon (error) value is exceeded, then you update the particle. But here's another possibly better idea. Have a single episolon value for each vertex in the mesh. This value is a distance. If the vertex has moved more than this distance since the last time you moved it, then you move it again and record the new distance. This will allow the particles to distort, but since we're going for smoothness, the distortion should be so small as to be undetectable anyhow. So for example, if you have a particle rotating around one corner, there is no need to move that corner vertex at all. The limitation of this sort of optimization is that fast moving particles won't be optimized at all. One other thing which I've been wondering is whether you could create a boned mesh, one bone per particle, and whether animating particles by moving bones would be faster. But to test this you'd have to make a B3D exporter and load the B3D in when you want to create a new set of particles, because Blitz provides no way to create bones and assign vertices to them at run time. |
| ||
| sswift: That doesn't still solve the biggest speed related issue with the particle system. Because the biggest slowdown occures even if you update a single vertex. |
| ||
| So... you're saying that regardless of how many vertices I update during a particular frame, the entire mesh needs to be re-sent to the card? And that THAT is what most slows down a single surface particle system, rather than transforming all those vertcies, or the sending of individual vertex updates to the card? Hm... well in that case, I wonder if bones are handled by the card's hardware, and if so, that might be a solution to the problem. |
| ||
| By batches, I meant polygon batches. There is a clear upper threshold. The AGP speed is part of this. It may be a lot quicker to upload 4x 500 poly meshes per frame than it is to upload one single 2,000 poly mesh. I think this will prove to be true once you go over 2,000 polys. |
| ||
| ROb, that doesn't make any sense. Why would it be faster to upload 4 500 poly meshes per frame instead of 1 2000 poly mesh? That makese no sense at all. |
| ||
| 114-126 Fps XP 1800+ Gf4 4600 @+ |
| ||
| sswift, he's right. My system benefits from not loading a single system with 2000 particles but 4 systems with 500. |
| ||
| My commons sense agrees with sswift here... why would 4x500polys be faster than single 2000 poly mesh?? You still have to send the same amount of polys thru AGP... and plus there should be some slowdown when handling 4 meshes (4 surfaces). But ShatteredRealitys experiments seem to prove otherwise?!? |
| ||
| It's really odd.... I don't understand it myself. ROB EXPLAIN! :) |
| ||
| Actualy this system I just posted currently runs at 60 updates per second which keeps things smooth obviously, asside from that there's a wide array of optimalization going on, to see if a particle actualy needs an update, including epsilon values as mentioned by swift, update flags set by modification functions and culling. On my system the 4000 poly surface performs about the same as the 4x1000 poly surface. As for the non realistic framerates, if I remove the particle update timing and epsilon the fps on my system goes down from around 330 to 160 fps. (that's with 2000 moving particles), so yes that's a fair bit less. Tho I concider atleast the epsilon system to be a fair enhancement! :P |
| ||
| Will you be releasing your particle system? |
| ||
| Did this today, because I need single surface font system for my game anyway... so this is integrated font/particle system. This is as fast as I could get it... http://www.kotiposti.net/naama/particles.zip EVERYTHING (velocities, rotation, vertexpositions etc.) is updated EVERY FRAME. HOLD space to see the maximum framerate |
| ||
| Btw. I can release the source if someone has any use for it. It's not commented at all though. |
   |