The power of surfaces?
Blitz3D Forums/Blitz3D Programming/The power of surfaces?
| ||
| They, i've been researching and test lately. I'm goin to work on my particle engine soon, but i heard something interesting, making them on a single surface system. So i'm guessing u draw all your sprites on one surface or something like that. Well, first thing i'm goin to do with my particle system is have a triangliar and rectangliar sprite system. I think that 2 tris is over kill in some cases (like a ball in a center of a texture. Just use one tri for that). So i'm guessing, I should make all my sprites as part of one BIG mesh instead of having many small meshes. Well, that sounds like an alright idea in some cases, but i won't be able to do some of the effects i'll probably want. Also animation wouldn't be based on move/position entity right, i'll have to recal all the vertices in the mesh if i want them to move kinda independly of one another. Would using a vertice repositioning code be faster than using positionentity? Single Surface sounds great for clouds. Multi Surface sounds great for rocks(the way i'm building it, u can just slap in an entity u want overall. So u can have a 3d rock spin with all the cals for movement) shooting out and having a smoke trail behind it(again, make the spawnpoint based on entities(mesh, to pivots). SO u can have the rock position as a spawn point automaticly) that does it's own thing(use global position to keep the smoke in one place and hae it alpha out). I'm thinking that'll be clearer and better than tryin to use a single surface system for that. Plus i can still have collision one the rocks. So what do u think? Should i have a mix system with optional single and multi surface options. Should i have the system be "partcile type" depend. So say the rock is multi surface system, but the smoke coming from the rock that just stays there in the sky...maybe have that single surface? Is the speed increase worth it? I would run test myself...but i haven't the time lately :(. Thanks for your help. |
| ||
| 1 Single tri particles are rarely (if ever) worth the overdraw, best to focus on square 2 poly ones. 2 The speed increase is well worth it. 3 You might want to not write your own and just use Lotus, ParticleCandy, or any other particle system already out there. |
| ||
| Me I just made a tri single surface sprite engine for my self and i only noticed the fps raised comparing to quad with alot less vertex modifications per update. But i guess if the screen is filled up with particles the quad would eat about half the fillrate of a tri? Perhaps I should put quad back in as an option. hehe. |
| ||
| Tris have another problem: Texture are square and when you put a square on a triangle, much of it will be cut which might cause quite some problems with a single surface system :) |
| ||
| Actually this is no problem. you just put the uv coordinates of the texture so its a square inside the tri. The problem is that by doing this, much of the space the tri occupies will be empty and quite probabbly eat up fillrate worth abit more than 2 quads of same size. I just wonder what is needed most in a normal gaming scenario. ability to cover the screen in more particles or to have the particles faster proccessed. |
| ||
| On a single surface system you will only have 1 textures for "all" particle graphics for example. So the wasted space of the tri might give problems afterwards On the other hand it is only half the amount of triangles ( only 1 vertex less per particle ) so if less graphics are needed it might be a quite good alternative |
| ||
| It's been said a couple of times before, but i think it's best to use one surface per emittor, that way the emittors off screen, don't need to be rendered, or processed. |
| ||
| The one texture per surface is ofcourse alil bit annoying. I guess one could press in more textures but then there will be alot of wasted texture memory with all the needed space between each texture. I use several surfaces. one per texture and then i sort sprites to different surfaces depending on how long away they are from eachothers in some way to try and limit fillrate and calculations. this rarely gives a good speed bonus though. |
| ||
| No need really. You can fit say mulitple particle images on the one texture, and choose which one you want to use, using texture coords :) |
| ||
| With quads this is no problem at all with different texture coords. Its just harder with a tri becourse the uv space one tri takes up to make a square fit inside is alot more than a quad. So there will have to be alot of blank space between each texture in the picture. |
| ||
| That's true. I'd just go with quads then ;) Alot easier for texturing :o) |
| ||
| See my signature for possible inspiration. |
| ||
| Well i did some speed tests now comparing triangle sprites vs quad and and the difference was quite big. With big sprites i got about double the speed with quads But with small ones like sparks it really is alot faster with triangles. so now i will use both hehe :) |
| ||
| With a auto-convertation function basing on onscreensize or what ;) |
| ||
| alright, U guys mention fillrates. My plan was to have V1.u = 0.5 V1.v = 1 V2.u = 0 V2.V = 0 V2.u = 1 V2.v = 0 yea, this will leave some space on the texture itself, i know this. I was planning on drawing inside the triangle area. If i used say a framed Texture method,(256x512 for ex) then i could put 3 different triangle textures in those slots. But that's not the true question, Say if i have a standard sized(256^2) texture, and i'll be using about half of its space. Does DX still try to render the area that isn't goin to be seen on the texture anyways? Y would having a triangle output on a texture slow things down? I'm assuming this surface business is less DX and more Blitz3d design for rendering. So u guys are sayin, make a mesh, get it's surface than add each vert in that. But for sayin partcicles falling down in kinda a different more random manner so that it doesn't look like all the particles are attach to some "point"(mesh overall orgin) in space , instead of using Scaleentity, i'll just make my own scale rounte that directly effect the verts and not the "mesh"(single tri mesh/sprites). I"m sure it could done easy, but i figure that if blitz does it in the background(move/position entity) it would be way faster than "outside" code handling it(making my own function for it, did they use assembly optimizing for some internal movements for example? I'm thinking whatever they did int he background would be better than what is custom code by the programmer because of blitz3d overhead) So what do u guys say about all that? |
   |