Im in need of advice and ideas.
Author
Im playing around with a simple 3d "Tile" engine and im currently rendering it intermediate, quite slow as you could guess, 30 fps for an ok sized map. Im to used to useing Heightmaps, im pretty good with those, (easy to work with). I played with a quad tree design it worked ok, not much speed increase over all.
from what I can guess, the main problem has to be all the glBegin/glEnd's I use cause I have to change textures every Quad, so im going to redesign the renderer. Basically I am out of ideas on how I should set it up to render things.
Heres a simple shot of what it looks like
for the standard tiles I have 5 textures, one on each side, and the top one, on the floating tiles I have 6.
Please dont just suggest "Use VAs, or USE VBOS" cause I want to, but its not like I have a model or a pool of triangles, its just a ton of raw heigh texture data, and at the moment im struggling to put it together into something usable, also any pointers on how to organize things together by texture would be helpful.
I tried a meathod to search a small list for exisiting textures, and add if if it wasn't there, took forever for the whole map. and then I tried creating a VA based on the textures by appending vertices to a list, the end result was frightful, took 8 min to load, and that was only with the top polygon being used. if I would ahve done all of them it would have taken me half the day...
anyway just looking for some insight on how others would approch the situation, sorry if I rambled on and on.
Current optimizations:
QuadTree, Was tested and either wasn't much help and at some points acctually hurt proformance, as most camera angles will show most of the map. so vision occlusion is not that helpful. (Removed for the time)
FaceCulling, a little helpful with buildings
Mipmapping, Large textures used to be my bottleneck
Dosn't Draw sides unless there is a side to show, havn't tried it with out but I guess its a big help :/
Current Speed 24-34 fps, Radeon 9800, 3ghz P4, WinXP
changing textures is your problem and batching is the answer, you shouldnt have to 'change texture every quad', looking at that picture you dont have many unqiue textures so batching really shouldnt be a problem, most of the road can be rendered in one batch, same for the land around the gas station, the pumps themselves etc
If working it out at runtime is really too slow (which, I find hard to belive) then you could always pre-process the map data and load it up all sorted
If working it out at runtime is really too slow (which, I find hard to belive) then you could always pre-process the map data and load it up all sorted
Author
Thanks for your time,
acctually its not changing textures, cause even if I remove all textureing from the app, it still runs at 30fps, but however I will say that my glBegin/glEnd Pairs are the problem, and yes I have so many cause I do use textures, so its indirectly related, so in a sence you are right. but anyway, unfotuanatly my meathod I came up with to batch them together was far to long, weather it was just that I can't think of another meathod of organizeing them then what I tried, as a mentioned, 8 min for top textures on runtime, and I can't precompile the data set, must be generated on the fly.
as I mentioned, I know some things that can fix the problem, its just that I can't find a Efficent meathod of doing it.
Hmm, I guess I could run thought the data 20 times, once for each texture, and render only those polys, but thats a large data set. I'll play with that idea and see how it turns out.
acctually its not changing textures, cause even if I remove all textureing from the app, it still runs at 30fps, but however I will say that my glBegin/glEnd Pairs are the problem, and yes I have so many cause I do use textures, so its indirectly related, so in a sence you are right. but anyway, unfotuanatly my meathod I came up with to batch them together was far to long, weather it was just that I can't think of another meathod of organizeing them then what I tried, as a mentioned, 8 min for top textures on runtime, and I can't precompile the data set, must be generated on the fly.
as I mentioned, I know some things that can fix the problem, its just that I can't find a Efficent meathod of doing it.
Hmm, I guess I could run thought the data 20 times, once for each texture, and render only those polys, but thats a large data set. I'll play with that idea and see how it turns out.
Author
ok well it was a good idea, but it failed, runs slower 18 fps. I guess the cpu killed it this time.
(spelling is likely to be dodgy, its late ya know, heh)
the imediate mode call are probably whats killinig you, what you'll need todo is pre-process your buffers producing sets of data for each texture and then throw all the verts at the card in one go, yes I'm talking vertex arrays (and later VBOs but for now getting it sorted that way)
Really, its just a matter of taking your drawing routine and instead of calling glvertex commands store off the (x,y,z) value for each batch and store them in an array, then when you hit drawing time its a simple matter of bind texture, bind array and draw.
Ofcourse, once you've got the basics up and running you'll want to look at reducing triangle count somehow, smaller blocks, quad trees, frustum culling, that sort of thing
the imediate mode call are probably whats killinig you, what you'll need todo is pre-process your buffers producing sets of data for each texture and then throw all the verts at the card in one go, yes I'm talking vertex arrays (and later VBOs but for now getting it sorted that way)
Really, its just a matter of taking your drawing routine and instead of calling glvertex commands store off the (x,y,z) value for each batch and store them in an array, then when you hit drawing time its a simple matter of bind texture, bind array and draw.
Ofcourse, once you've got the basics up and running you'll want to look at reducing triangle count somehow, smaller blocks, quad trees, frustum culling, that sort of thing
Author
Hmm I dont know what it is but what you said inspired me to try something, well as far as that goes, the acctual structure is being generated in realtime, it isn't in an array of data, im generating it like
Im gonna try to render it into data, I got an idea that should be MUCH more efficent then my previous undertaking, and less confusing, that one had me just stairing at the moniter wondering if it was possible in the end. I'll give it a shot and report back, thanks again for helping.
glVertex3f(Left,Height[0],Right );glVertex3f(Left+1,Height[1],Right );glVertex3f(Left+1,Height[2],Right+1 );glVertex3f(Left,Height[3],Right+1 );Im gonna try to render it into data, I got an idea that should be MUCH more efficent then my previous undertaking, and less confusing, that one had me just stairing at the moniter wondering if it was possible in the end. I'll give it a shot and report back, thanks again for helping.
Author
haha! I got it working, I dont remember what I was originally doing that took 8 min but what ever it was must have been brain dead wrong, cause I can do it now in a second =D around 18 times a second, heh, useing the same concept as my last drawing attempt I can now compile the data into a wonderful VA structure, organized by textures, so I can now draw its at 90 fps, I hope to impliment Vbos and see how fast I can get it. thanks for the push in the right direction.
Current Speed 90-104 fps, Radeon 9800, 3ghz P4, WinXP
Current Speed 90-104 fps, Radeon 9800, 3ghz P4, WinXP
Just dump the drawing code into a display list at load time and draw it, you should get speeds equivalent to VBOs.
Note: This only applies to static data.
Note: This only applies to static data.
Author
Quote:Original post by GamerSg
Just dump the drawing code into a display list at load time and draw it, you should get speeds equivalent to VBOs.
Note: This only applies to static data.
no, you wont, that was already tested on my part, I recved a 1-5 fps improvement. With out batching the D-lists it dosn't help.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
