Archived

This topic is now archived and is closed to further replies.

iNsAn1tY

The scale of things...

Recommended Posts

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
>>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? <<

come again!!!

read the first post again - obelix''s

Share this post


Link to post
Share on other sites
If you have less to draw, you will see a performance increase.
Oddly enough, this is not the case apparantly on my GeForce2GTS, where no matter how big the window on my screen is, it will still rotate the triangle at the same speed. My laptop with some crap 2.5 MB video card, apparantly doesn''t support OpenGL except in software, which makes the rotation of that same triangle faster in a smaller window. If the window is maximized, the rotations are waaaaaaaay slow.

So, if you make a smaller wall, it really does depend on how big it appears on your screen I think. I mean, a lot has to do with how the textures are mapped and such, but if it doesn''t appear on the screen, I would guess the performance would increase a lot.
Still, smaller means less to do, but it might also mean less detail. I am still learning OpenGL and I haven''t gotten to texturing, but hey, if this helps, I did my job. Otherwise, please correct me (nicely!).

Share this post


Link to post
Share on other sites
ok
the size of the wall makes absolutely NO difference it can be 1mm across or 1km (difference 1000000:1), both will be rendered at the same speed.
what makes a difference is fillrate ie how many pixels have to be drawn on the screen (the size of the object makes no difference ie a wall 1mm across will look as big as a wall 1km if u move the camera 1,000,000x closer)
all cards suffer from fillrate limits from software opengl -> geforce3 its the reason why most apps run faster at 320x200 than 1600x1200.
with software implementations certain things are very slow (the per pixel things) thus blending + texture mapping etc are a nono (lighting is relativelly ok because its done per vertex)

Share this post


Link to post
Share on other sites
couple of things I would like to bring to this quickly.

firstly, dont think of things in terms of pixels, think in terms of units, this to me was the main key to understanding 3D worlds and vectors etc.

secondly, in Half-Life the player models was 72units high, 32 wide, 32 deep. 72/12 = 6ft, therefore each world unit = 1inch in HL

So, when defining your maps or models, make the objects render so they are ''x'' units tall, wide etc
so a wall 72 high, 72wide and 5 deep would be 6ft tall, 6ft wide and 5ft deep in real terms (based on the hl scale) And if drawn with those dimentions would scale correctly regardless of what res the person is using.

------------------------------
Phantom
m00!

Share this post


Link to post
Share on other sites
Thanks for all the input, people. I really needed to get this straight in my head. I re-thought my systems, based on your posts, and re-wrote some of them. My engine appears to be running faster, even though most of the changes were pretty minor.

I''m now moving on to multi-texturing, for my lightmap lighting, but before that, I gotta write a raycaster to put the maps through to generate the luminance TGAs I''ll be using. Oh well, no rest for wicked, eh?

Thanks again...

iNsAn1tY - the place where imagination and the real world merge...
Try http://uk.geocities.com/mentalmantle

Share this post


Link to post
Share on other sites