Probable Single Surface Improvement
Blitz3D Forums/Blitz3D Programming/Probable Single Surface Improvement
| ||
| CLUSTERED SINGLE SURFACE PARTICLES - When creating single surface particle systems, its common to create a single - mesh, updating all the verts with one simple update() call. - There is big problem with this approach, assuming the quantity of verts exceeds - a given system dependent amount - "bottlekneck". The time it takes to both transfer and - update the vertex data on the card...AGP speed & other factors determine how much data - you can send before a significant framerate drop occurs..... - One solution..is to break the single surface system into clusters - groups of single surface - meshes. You then update the verts in these clusters throughout the gamecycle, so perhaps - updating a cluster after I/O processing, and another cluster after some other operation.. - - The idea is quite simple, you send bursts of small/medium sized data sets to the - graphics card, do some game processing & the send more data. This prevents the - cpu from wasting cycles waiting..the more data that must be sent the longer the - cpu idles waiting for the data to complete transfer + the card to update itself... [perhaps 100 quads per surface/cluster is reasonable?] The speed gains my not be great..i havent tested the concept....but its worth a shot - i might try moding bloodlocusts single surface system to work like this.. but i have heaps of more important code to get finished in my own project... anyway - perhaps someone could try this out + post results? |
| ||
| Why don't you just only update the particles right before a render? |
| ||
| Right..well the truth is i dont know exactly how the AGP, CPU, memory communicate...But for the sake of argument, lets say its similar to buffered operations... Once the buffer is full..you cannot add to the buffer, + must wait til its empty, or atleast some free space exist.. If this is the case..it doesnt matter when you edit the verts..but its best to be able to send a block without waits than the whole thing with waits... Imagine this... you have 100 units and a buffer takes 10 units at a time +you have to wait 5 minutes til it empties before filling it again.....you also have some other function that takes approx 5 mins to process... It also takes 5 mins to copy 10 units to the buffer.. 1]pass 10 units - 5 mins to send 2]call function - this takes 5 mins... 3]pass next 10 units...5 mins Those steps waste no cpu cycles...15 mins tot time... 1] pass 20 units into buffer = 5 mins to send 10 = 10 mins = 5 mins to between sends = 15 minutes 2] call function = 5 mins.... Total=20 mins...wasting 5 mins waiting Ok thats a silly exageration..but you get the picture? - Of course im unsure how successful the idea is..it may be utter crap...but i wont know til ive tried it out..... anyway..like i said..if anyone can be bothered..why not give it a shot...well if your really bored :p |
| ||
| One mesh entity per emitter is the most efficient way to do it in Blitz. |
| ||
| One mesh entity per emitter is the most efficient way to do it in Blitz. what do u mean? |
| ||
| Blitz handles how stuff is sent to the video card, so if you're talking about trying to avoid buffer waits on the AGP by updating meshes during your game loop at speciifed intervals to improve speed, I doubt it will work. Drey: An emitter is an object that emits a specified number of a specific type of particle, at a specified rate, from a specific location, in a specific direction, for a specific period of time. Ie, an explosion occurs. You create an emitter that emits 100 smoke particles over the course of 3 seconds. Those smoke particles all belong to a single mesh which is specific to that emitter. When the emitter's lifespan expires, and all the particles it was to emit have expired, the emitter mesh is deleted. |
   |