The scale of things...
One thing that has bugged me from the start about my 3D engine is the scale of things.
I have set a size of 96px for the size of my player, who is 6ft tall in real terms. This means that a foot is 16px, which is a nice scale to render to. If I want a room that's 20ft square, all I do is multiply that by 16 and I have the the size in pixels of the walls.
Now, I don't have the fastest computer in the world (the laptop I use has a bare bones 3D card, and the high end machine I use for games blew up the other week), but I have noticed a significant slow down in rendering even one object, a wall with 12 polygons, which is about 96x8x288. It's a large polygon, and I'm now beginning to wonder about my scale of 1ft = 16px. Is this too large?
I just opened one of NeHe's tutorials (a conversion, written in VB) and saw a beautiful 3D textured square, like the ones in my 3D engine. I looked at the code, and was quite amazed to find that the cube was only one pixel square.
The reason I settled on 96px = 6ft is because I used Half-Life's WorldCraft map maker to create rectangles of different sizes. The one which matched the player's height most accurately (ie. it was just a little higher than eye level) was 80px high. I reckoned the HL player was about 6ft, so I make my scale a power of 2 (96px / 6ft = 16px = 2x2x2x2), to make life easier.
With all this background I have one question: should I change the scale of my system, in order to make polygons smaller?
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
Edited by - iNsAn1tY on January 8, 2002 8:14:49 PM
Saying that a cube is one OpenGL unit has nothing to do with pixels. Making it one or 10000 units wide does not affect the speed. Everything is relative so the only existing scale is how big the object is compared to the other objects. If you multiply all objects with the same constant do you get the result. Why not use a natural system instead of converting it to some "pixel" scale?
It''s dangerous to directly relate OpenGL units to pixels, since this will totally screw up, as soon as the user switches to another resolution.
Just choose an initial scale. It can be arbitrary, but take things like floating point accuracy and depth buffer precision into account.
This scale would relate 1 unit to a certain realworld size. Say 1 unit = 1 cm (or perhaps 1 unit = 1 inch, for Americans ). Now you model everything respecting that scale, and you''ll be fine, at all resolutions. The OpenGL projection stage will rescale everything to the right screen dimensions.
The only thing to readjust manually are the depth range and the camera''s FOV.
- AH
Just choose an initial scale. It can be arbitrary, but take things like floating point accuracy and depth buffer precision into account.
This scale would relate 1 unit to a certain realworld size. Say 1 unit = 1 cm (or perhaps 1 unit = 1 inch, for Americans ). Now you model everything respecting that scale, and you''ll be fine, at all resolutions. The OpenGL projection stage will rescale everything to the right screen dimensions.
The only thing to readjust manually are the depth range and the camera''s FOV.
- AH
Well, Obelix, I just thought it would be easier if I had a pixel-to-real-world conversion for when I was creating maps. Like I said, If I want a room that''s 20ft square, I can very simply enter that value multiplied by the pixel conversion value into a map maker, and make a wall I know is the correct size.
Thanks for pointing out that all the sizes are relative. I hadn''t thought about it from that angle before. I suppose that it''s the amount of screen the polygon actually covers that affects performance. However...
When you draw a large polygon in OpenGL, the speed is slower compared to when you draw a small polygon (at least it seems that way to me). So, should I draw my polygons smaller (by reducing the pixelto-real-world conversion value) to increase speed, or leave them as I have them?
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
Thanks for pointing out that all the sizes are relative. I hadn''t thought about it from that angle before. I suppose that it''s the amount of screen the polygon actually covers that affects performance. However...
When you draw a large polygon in OpenGL, the speed is slower compared to when you draw a small polygon (at least it seems that way to me). So, should I draw my polygons smaller (by reducing the pixelto-real-world conversion value) to increase speed, or leave them as I have them?
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
With my geforce2 I can happilly run over 1 million polygons without any difference in lag or fps whether a side is 0.01f or 1.0f.
What I do for all my stuff that is to use any real world dimensions is make each unit a standard SI unit. So for example, if I was making a car game or 3d shooter style game, I would have 1.0f = 1 metre. If I were to make something like a strategy game where everything is tiny on the screen, it would usually be 1.0f = 10 metres so I wouldn''t have to type in as many zeros. For cad stuff it would be 1.0f = 1 millimetre. Just choose the most suitable and easiest scale for your program so you won''t get confused. After you create a file format for your models and "world", it will become easier.
thats my advice anyway.
Beer - the love catalyst
good ol'' homepage
What I do for all my stuff that is to use any real world dimensions is make each unit a standard SI unit. So for example, if I was making a car game or 3d shooter style game, I would have 1.0f = 1 metre. If I were to make something like a strategy game where everything is tiny on the screen, it would usually be 1.0f = 10 metres so I wouldn''t have to type in as many zeros. For cad stuff it would be 1.0f = 1 millimetre. Just choose the most suitable and easiest scale for your program so you won''t get confused. After you create a file format for your models and "world", it will become easier.
thats my advice anyway.
Beer - the love catalyst
good ol'' homepage
Thanks, I think I''ll do that. As my game engine''s an FPS, I''ll use something like a 1.0f = 1 metre scale. That could be really useful. But if all my characters are about 1.5f high, will that cut down on the detail that can go into them, and will I need to use glScalef on every polygon of every model to make it small enough to fit in the scene? Because obviously, I can''t use something like gmax on that kind of scale.
I suppose I could always create the model in gmax, then, while I''m convering it to my native model format, I could put in an algorithm to scale all the polygons correctly, so I don''t have to call glScalef all the time, and incur some really big performance problems...
If I could find it, I''d like to know how Quake III or Half Life scaled their characters. They create them quite large, as I''ve opened *.md3 files from Quake III, in milkshape, but they must need to scale them inside the engine if they use a scale as small as 1.0f = 1 metre.
Damn, this is really doing my head in...
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
I suppose I could always create the model in gmax, then, while I''m convering it to my native model format, I could put in an algorithm to scale all the polygons correctly, so I don''t have to call glScalef all the time, and incur some really big performance problems...
If I could find it, I''d like to know how Quake III or Half Life scaled their characters. They create them quite large, as I''ve opened *.md3 files from Quake III, in milkshape, but they must need to scale them inside the engine if they use a scale as small as 1.0f = 1 metre.
Damn, this is really doing my head in...
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
OK, now I have to look stupid. I just opened the md3 for Sarge, from Quake III, after considering some of my comments in the above post. I have discovered that the legs part of him (by default the legs and upper body of Quake III character is rendered independently of each other) is only about 16px wide, 44px high and 12px in depth. The upper body part is about 17.5px wide, 20px high and 14px in depth. Add the two totals together, and what do you have for the height? About 64px high. A nice, round, power-of-two number. I must have missed this last time I opened the file to examine it.
Now, knowing that Quake code will obviously not call glScalef for every polygon, due to the performance slowdown, I''m assuming that the model is loaded and rendered using the exact coordinates as they appear in milkshape. So I''m going to do the same, and choose a pixel to real world conversion factor. I might use 64px = approx. 6ft, perhaps. Does that make sense? I hope so...
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
Now, knowing that Quake code will obviously not call glScalef for every polygon, due to the performance slowdown, I''m assuming that the model is loaded and rendered using the exact coordinates as they appear in milkshape. So I''m going to do the same, and choose a pixel to real world conversion factor. I might use 64px = approx. 6ft, perhaps. Does that make sense? I hope so...
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
I think I see what you are getting at. Well firstly I personnaly I never use the glScaleXX() functions.
If I have to convert between formats, the best thing to do is to convert it when you LOAD in the image from the data files, and then you convert them back when you SAVE the file again.
So lets say you had 96 units = a 6 foot bloke. That is around 180cm. So 96units = 1.80m. So when you load it yuo would multiply all of the units (eg, 96 or 48 units) by (1.8f/96.0f).
When you save it you would change your float (1.0f = 1 metre, 2.0f = 2 metres) by (96.0f/1.8f).
This way you can work in the more "brainy (as in the Smurf)" format and then convert it back to the more awkward format later.
This pretty much goes with everything. Another example would be laoding a file in Imperial mesurements, but using metric to edit it. Makes it simple.
If I have to convert between formats, the best thing to do is to convert it when you LOAD in the image from the data files, and then you convert them back when you SAVE the file again.
So lets say you had 96 units = a 6 foot bloke. That is around 180cm. So 96units = 1.80m. So when you load it yuo would multiply all of the units (eg, 96 or 48 units) by (1.8f/96.0f).
When you save it you would change your float (1.0f = 1 metre, 2.0f = 2 metres) by (96.0f/1.8f).
This way you can work in the more "brainy (as in the Smurf)" format and then convert it back to the more awkward format later.
This pretty much goes with everything. Another example would be laoding a file in Imperial mesurements, but using metric to edit it. Makes it simple.
Ok, here may be your problem since you didnt really describe how you actually draw your objects:
DO YOU SCALE YOUR OBJECT EVERY RENDERING FRAME??
If so, just cut that shit out! Like dredge says, all game objects, at initialization SHOULD BE SCALED BEFORE such an object is actually used. 1 scale is better then X number of scalings per second.
As for scale in general, I had the same questions myself. Someone answered these under the "game programming" forum about 2 months ago. You should do a search first, as the guy who helped me gave answers just like dredge!
DO YOU SCALE YOUR OBJECT EVERY RENDERING FRAME??
If so, just cut that shit out! Like dredge says, all game objects, at initialization SHOULD BE SCALED BEFORE such an object is actually used. 1 scale is better then X number of scalings per second.
As for scale in general, I had the same questions myself. Someone answered these under the "game programming" forum about 2 months ago. You should do a search first, as the guy who helped me gave answers just like dredge!
No, obviously, I''d scale eveything as I loaded it in, not every frame.
OK, Dredge, let me think about this...
I load in a file with a wall about 96px in width, 288px in length and 8px in height, which has been created using my 1ft = 16px scale.
Now, I multiply it by my internal scale, which is about (1.80m / 96px). This gives me a wall which is: 1.8px in width, 4.78px in length and 0.15px in height. This would be done as I loaded the map file, and nothing but the vertices would need changing (all the normals and texture coords would be the same).
OK, the newly modified wall is very small. This would cut down on the amount of drawing OpenGL would have to do, yeah? And overall performance would be increased?
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
OK, Dredge, let me think about this...
I load in a file with a wall about 96px in width, 288px in length and 8px in height, which has been created using my 1ft = 16px scale.
Now, I multiply it by my internal scale, which is about (1.80m / 96px). This gives me a wall which is: 1.8px in width, 4.78px in length and 0.15px in height. This would be done as I loaded the map file, and nothing but the vertices would need changing (all the normals and texture coords would be the same).
OK, the newly modified wall is very small. This would cut down on the amount of drawing OpenGL would have to do, yeah? And overall performance would be increased?
iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement