image pixelssize and quad+texture pixelssize
Blitz3D Forums/Blitz3D Programming/image pixelssize and quad+texture pixelssize
| ||
| Hello, My code seems to work well to have a quad+texture which uses the same pixelssize (the same area in pixels) than the image, see : however i wonder why if i use the graphics height instead of the graphics width to calculate the quad size, then the quad+texture pixelssize (the area in pixels) is bigger ? |
| ||
| The math works out that way. The height is less than the width. If you divide something by the width you get a value. If you divide something by the height, since the height is less, the result is bigger. For example: value = 10 width = 5 height = 2 value / width = 2 value / height = 5 ;The result is bigger, so your mesh is bigger. |
| ||
| The height is less than the width. If you divide something by the width you get a value. If you divide something by the height, since the height is less, the result is bigger. @Kryzon>>thanks, i understood this... my question was more why the quad has the same pixels area than the image if i use the graphics width as the divider but not if i use the graphics height as the divider (why the quad is shaped this way) Maybe this is arbitrary ? Whatever, this is not important, just by curiosity. |
| ||
| Here are 2 examples to illustrate what i mean : graphicswidth 500, graphicsheight 250 if i use graphicswidth as the divider, the pixels area used by the quad is the same than the pîxels area used by the image if i use graphicsheight as the divider, the pixels area used by the quad is bigger than the pîxels area used by the image graphicswidth 250, graphicsheight 500 if i use graphicswidth as the divider, the pixels area used by the quad is the same than the pîxels area used by the image if i use graphicsheight as the divider, the pixels area used by the quad is smaller than the pîxels area used by the image why ? |
| ||
| Oh sorry, I understand it better now. I'm not certain why it happens, but it has to do with the field-of-view (the zoom). If you do CameraZoom( camera, 0.75 ) in that code you posted, then using the height keeps the same size where the width has the differences. 0.75 = 480 / 640 (Not sure why this is so, though, it's boring perspective projection stuff.) |
| ||
| It's not a coincidence. You are setting up the mesh so it's on-screen width exactly matches the image. With the default camera setup the viewing plane is at a distance of 1 in front of the camera and zoom factor is 1. The visible area extends in the 3D world from -1 to +1. With, for example, Graphics3D set to a width of 640 the screen is 640 pixels wide with x = 320 being the vertical center line. The left half is 0 to 320 and the right is 320 to 640. The mesh has a half-width of 8/640 = 1/80. The center of the mesh is positioned at screen x = 320. The mesh extends 320/80 pixels to the left and right. So the left edge is at screen 316, the right edge at 324. This matches the image. |
| ||
| (Not sure why this is so, though, it's boring perspective projection stuff.) i think that this is arbitrary (a choice to have it this way by Mark) But since in most cases (on desktops screens and on laptops screens) the graphicswidth is bigger than the graphicsheight, it is not a problem since we know we can always use the graphicswidth as the divider. @Floyd>>apparently you don't understand what i mean (or i don't understand what you mean :P), try to modify the code with my 2 examples in post #4, you will see |
| ||
| Everything I said applies to other numbers besides 640. I chose that because the arithmetic was easy to understand. Using your variable WH instead of 640 the screen halves left and right are x=0 to x=WH/2 and x=WH/2 to WH. The mesh has a half-width of 8/WH etc. With the WH = 500 example the screen halves are 250 pixels wide. The mesh has a half-width of 8/500 which is mapped into half the 500 pixel wide window, occupying (8/500)*250 = 8/2 = 4 pixels. So the mesh appears on screen as 8 pixels wide. The same considerations apply to height. The view plane again goes from y=-1 to y=+1, just as with x. So the mesh displays as 4 pixels high. Note the -1 to +1 limits imply a square area, so x and y are to the same scale. But this region is clipped ( not scaled ) to fit the window/screen. The width=500 example uses a 500x250 window. Using WH = 500 makes the mesh display as 8x8 pixels. Using WH = 250 defines the same window, but the mesh calculations use 1/250, which is 2/500, so the mesh is twice as big. As you can see from trying it the 250x500 window and WH = 250 = width also gives 8x8 pixels for the rendered mesh. So Graphics3D, width, height is using the width to set up the correspondence of view plane to screen even when width is less than height. I don't know if this was an arbitrary choice or some kind of D3D7 convention. Since width is just about always greater than height for desktop 3D it seems like a reasonable choice. |
| ||
| So Graphics3D, width, height is using the width to set up the correspondence of view plane to screen even when width is less than height. yes that's what i meant, and i think this is arbitrary, not a problem, just interesting to know... |
| ||
| Maybe this is not exclusive to Blitz3D and can also happen in other engines. What is the ratio of your game screen if the screen dimensions are 640 x 480? There are two ratios, (width / height) or (height / width). Blitz3D happens to use (height / width), which means the ratio of that game screen as a fraction is 1 : 0.75. It happens that a 3D camera has two field-of-view angles: a horizontal and a vertical one. When you use CameraZoom you're changing only the horizontal angle. The vertical angle is derived from the horizontal angle using that ratio, like in the case of 1 : 0.75: verticalZoom = horizontalZoom * 0.75 This means that the dimensions of the near-plane of the camera with a default 1.0 zoom, no matter the screen resolution, is always 1 x (height/width) 3D units. In that 250 x 500 screen the size of the near-plane by default is 1.0 x 2.0 3D units. The size of the near-plane changes as you zoom in and out, but that ratio stays the same (otherwise the graphics would feel distorted). Check function GenerateProjectionMatrix in this, I remember testing it until it matched the native Blitz3D cameras: http://www.blitzbasic.com/Community/posts.php?topic=100959#1196765 Also this: http://www.scratchapixel.com/lessons/3d-basic-rendering/perspective-and-orthographic-projection-matrix/building-basic-perspective-projection-matrix |
| ||
| You might also take care of camera scale (ScaleEntity on the camera or its parent(s)), it can modify the camera ratio if scaleX<>scaleY (and scaleZ actually modify the zoom factor) |
| ||
| Z-scaling the camera gives a weird compression effect, you can see here: http://www.blitzbasic.com/codearcs/codearcs.php?code=3014 I think it has to do with all vertices being transformed by the camera, so scaling it is like changing the whole scene. |
   |