My Level Editor Problem
I am making a level editor so I can get all those nasty coordinates into a file without me having to type them. Currently I am able to create a cube, manipulate its vertices if I need to and show it in three 2D screens and one 3D screen using 4 viewports. Everything was going fine because, the stage that I was at all my polys rendered in 3D weren''t textured, just coloured. But now I am about to assign texture ID''s to each to the polys and I added a bitmap loading function. But now all my gridlines that I drew using GL_LINES and vertice points using GL_POINTS are really dark after loading in my textures , I can''t hardly see them anymore. Does anyone know a way to lighten all my non-textured lines/points, and even some of the 3D polys that will at the start have no texture''s assigned to them. I hope you understand what I mean and all suggestions are appreciated.
Thanks
I cant help you with your untextured polys. But for the lines:
You have to write glDisable(GL_TEXTURES_2D); just before you draw the lines, after that you can re-enable it.I think that have to do.
You have to write glDisable(GL_TEXTURES_2D); just before you draw the lines, after that you can re-enable it.I think that have to do.
hey, life has to go on
Thanks, that''s done the trick.
I''m gonna ask another quick question, which I believe is about fillrate. In my 3D window, when I have around 35 brushes, since they are all cuboids thats 210 polygons it starts to become very slow, CULL_FACE isn''t enabled because all the polys aren''t inputed clockwise/counter..., I plan to just do this when outputing to a file, I thought that performance in the level editor isn''t overly important.
Anyways, when I put these 210 polygons in the one spot and walk towards it its very slow, but if it isn''t onscreen the framerate picks up alot. Now since they are all still being rendered in the loop I have, does this mean the problem is fillrate. If so, what is it?
Thanks again, and sorry if I sound stupid.
I''m gonna ask another quick question, which I believe is about fillrate. In my 3D window, when I have around 35 brushes, since they are all cuboids thats 210 polygons it starts to become very slow, CULL_FACE isn''t enabled because all the polys aren''t inputed clockwise/counter..., I plan to just do this when outputing to a file, I thought that performance in the level editor isn''t overly important.
Anyways, when I put these 210 polygons in the one spot and walk towards it its very slow, but if it isn''t onscreen the framerate picks up alot. Now since they are all still being rendered in the loop I have, does this mean the problem is fillrate. If so, what is it?
Thanks again, and sorry if I sound stupid.
fillrate, that''s the amount of pixels your graphic card can draw per second. It differs under some circumstances (for example, on old graphic cards (voodoos for ex.) if you draw a polygon with two textures, it will need to draw it twice (once per texture), modern cards can often draw 2(tnt and later for ex.) and sometimes even 3(radeon) or 4(geforce2/3?, not sure thru) textures per polygon point in one cycle, therefore they don''t draw a polygon twice/more times to mix additional textures.
But back to your question, if you draw a lot of large polygons (esp. close to fullscreen) you reach the fillrate limit pretty fast. On my TNT card (yeah, old and crappy) drawing 10 fullscreen polygons makes a big hit to my fps rate (often makes it sink several times - they are also hungryds of small polygons around). The problem looks like this, let us assume you have got a fillrate of 100 Milion pixels per second. To get a decent 25fps animation (actually you should rather aim for ~60fps, 30fps is pretty much the minimum for smooth animation) you need to redraw all the graphic 25 times, so you can divide the fillrate by 25, you end up with 4 Milion pixels per second... pretty much? Not at all! If you take an often used mode - 1024x768 pixels and you do the math (1024*768) you will notice that you end up doing having 800k pixels on screen... so divide 4000k/800k and you end up with 5 screen redraws per frame! So drawing 5 faces, where every face fills the whole screen, would make you reach the 25fps mark! And also, that''s pretty theoretical, if you use a lot of polygons then the fillrate is partially wasted because graphic card is waiting for data from cpu (and also it takes a moment to send all data thru the bus) so actual fillrate in a game is lower(not much thru).
Actual numbers for modern 3d cards are between 300-1000M pixels per second(with 2 or more textures on a single pixel per cycle) and screen resolutions that ppl use are between 800x600 and 1280x1024. But you can see, that with big polygons you can come to the fillrate barrier pretty fast. Most games has an overdraw rate around 3-4. Some drop under 2, but that''s rather quite rare I guess.(overdraw means, that you draw one pixel several times, while drawing different polygons. There are many tricks and algorithms to decrease the overdraw)
You should also take one point, that fillrate isn''t the only limiting factor, on the other end you will find that cpu/gpu speed can be also a limiting factor if you use a large quantity of small polygons - cpu has got a lot of calculations, but graphic card doesn''t use much fillrate because polygons are small)
Here are few ideas to help you on the fillrate problem:
1.If you really have problems, use lower resolution mode.(it''s a bad practice thru
2.if you draw a lot of medium-size or big polygons sort them by z and draw them from the closest one(smallest Z value) This way your graphic card will pretty fast check, that there''s a pixel with a lower z-value in the z-buffer and it won''t waste as much time drawing this pixel as it would if it had to draw this point to the screen.
3.use backface culling, really helps a lot (for me it cut down the number of drawn polygons by around 25-33%)
4.Look for a smart algo that helps you find polygons that are hided(at least partially) behind other polygons. If you use this algorythm on big polygons you might pretty fast end by drawing only few of them and dropping the rest that''s not visible. Such algorithms are often quite hard to code/understand and therefore they aren''t rather something you should try if you''re not a good programmer with a decent understanding of math.
Ok, this ports grew long pretty fast
I hope it helps a bit, for further information you should look for some hardware sites (if you need more info on fillrate, they might describe it much better then I did) and also check gamedev articles, a lot of tricks and algos for 3d graphic programming.
With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/
But back to your question, if you draw a lot of large polygons (esp. close to fullscreen) you reach the fillrate limit pretty fast. On my TNT card (yeah, old and crappy) drawing 10 fullscreen polygons makes a big hit to my fps rate (often makes it sink several times - they are also hungryds of small polygons around). The problem looks like this, let us assume you have got a fillrate of 100 Milion pixels per second. To get a decent 25fps animation (actually you should rather aim for ~60fps, 30fps is pretty much the minimum for smooth animation) you need to redraw all the graphic 25 times, so you can divide the fillrate by 25, you end up with 4 Milion pixels per second... pretty much? Not at all! If you take an often used mode - 1024x768 pixels and you do the math (1024*768) you will notice that you end up doing having 800k pixels on screen... so divide 4000k/800k and you end up with 5 screen redraws per frame! So drawing 5 faces, where every face fills the whole screen, would make you reach the 25fps mark! And also, that''s pretty theoretical, if you use a lot of polygons then the fillrate is partially wasted because graphic card is waiting for data from cpu (and also it takes a moment to send all data thru the bus) so actual fillrate in a game is lower(not much thru).
Actual numbers for modern 3d cards are between 300-1000M pixels per second(with 2 or more textures on a single pixel per cycle) and screen resolutions that ppl use are between 800x600 and 1280x1024. But you can see, that with big polygons you can come to the fillrate barrier pretty fast. Most games has an overdraw rate around 3-4. Some drop under 2, but that''s rather quite rare I guess.(overdraw means, that you draw one pixel several times, while drawing different polygons. There are many tricks and algorithms to decrease the overdraw)
You should also take one point, that fillrate isn''t the only limiting factor, on the other end you will find that cpu/gpu speed can be also a limiting factor if you use a large quantity of small polygons - cpu has got a lot of calculations, but graphic card doesn''t use much fillrate because polygons are small)
Here are few ideas to help you on the fillrate problem:
1.If you really have problems, use lower resolution mode.(it''s a bad practice thru

2.if you draw a lot of medium-size or big polygons sort them by z and draw them from the closest one(smallest Z value) This way your graphic card will pretty fast check, that there''s a pixel with a lower z-value in the z-buffer and it won''t waste as much time drawing this pixel as it would if it had to draw this point to the screen.
3.use backface culling, really helps a lot (for me it cut down the number of drawn polygons by around 25-33%)
4.Look for a smart algo that helps you find polygons that are hided(at least partially) behind other polygons. If you use this algorythm on big polygons you might pretty fast end by drawing only few of them and dropping the rest that''s not visible. Such algorithms are often quite hard to code/understand and therefore they aren''t rather something you should try if you''re not a good programmer with a decent understanding of math.
Ok, this ports grew long pretty fast

With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/
With best regards, Mirek Czerwiñski
blah, sorry for my bad english, mixing words (like using they instead there) and other crappy things. I suxx, that is my line of defense. I consider getting better thru
Who wants to teach me proper english?
With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/


With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/
With best regards, Mirek Czerwiñski
god, I have read my whole post... shut me. I shouldn''t be considered as being worth the bullet thru, so better get a baseball bat or something
With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/

With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/
With best regards, Mirek Czerwiñski
Hehe, your English is great, there''s no point in getting the baseball bat =) The purpose of the post is to helt other people understand what you''ve written, not debugging you english as it was a english exam or something
Kenneth Wilhelmsen
Download my little game project HERE
--------------------------
He who joyfully marches to music in rank and file has already earned my contempt. He has
been given a large brain by mistake, since for him the spinal cord would fully suffice. This
disgrace to civilization should be done away with at once. Heroism at command, senseless
brutality, deplorable love-of-country stance, how violently I hate all this, how despicable and ignoble war is; I would rather be torn to shreds than be a part of so base an action! It is my conviction that killing under the cloak of war is nothing but an act of murder

Kenneth Wilhelmsen
Download my little game project HERE
--------------------------
He who joyfully marches to music in rank and file has already earned my contempt. He has
been given a large brain by mistake, since for him the spinal cord would fully suffice. This
disgrace to civilization should be done away with at once. Heroism at command, senseless
brutality, deplorable love-of-country stance, how violently I hate all this, how despicable and ignoble war is; I would rather be torn to shreds than be a part of so base an action! It is my conviction that killing under the cloak of war is nothing but an act of murder
Thanks mate, just wanted to tell you that such a long and detailed post is much appreciated since it obviously took you a decent bit of time to write.
They are good suggestions on how to drop the fillrate, I will try and include them into my 3D engine that I will make after the level editor. But the problem is I don''t want to complecate the editor too much or it will have it''s own built in 3D engine which will drastically increase the time to finish it, I''m trying to finish this before I go back to school! (Halloween break).
Your suggestions will be most helpful when I begin coding my 3d engine (if you want to call it that, sounds a bit professional for me).
As for my poor framerate, I think its because the polygons I was creating were about 100-200 gl units long, which is a bit big, which as you mentioned isn''t helping the fillrate.
Thanks again
They are good suggestions on how to drop the fillrate, I will try and include them into my 3D engine that I will make after the level editor. But the problem is I don''t want to complecate the editor too much or it will have it''s own built in 3D engine which will drastically increase the time to finish it, I''m trying to finish this before I go back to school! (Halloween break).
Your suggestions will be most helpful when I begin coding my 3d engine (if you want to call it that, sounds a bit professional for me).
As for my poor framerate, I think its because the polygons I was creating were about 100-200 gl units long, which is a bit big, which as you mentioned isn''t helping the fillrate.
Thanks again
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement