floting-point camerazoom distortion
Blitz3D Forums/Blitz3D Programming/floting-point camerazoom distortion
| ||
| I'm making an fps/tps but ran into a problem a while ago. When in third person mode, to get an adequate view of your surroundings, the camera must be placed outside of the characters collision radius. But this allowed the camera to go through objects. To correct this problem I moved the camera inside the radius and gave the camerazoom a value of 0.2. However, this results in severe distortion of the image somewhat like looking at a strongly concave mirror. I finally corrected this problem by putting the camera's image on a convex square and watching the square through another camera. This works, but takes up significant system resources. To make it worse, this is a multiplayer game, and this technique will have to be used on all the players to make it look good Could you use a simple mathematical formula to correct the problem? |
| ||
| You lost me at "to correct this problem.." Why is it even a problem that the camera needs to be outside of the character's collision radius? |
| ||
| The camera really shouldn't be colliding with the player anyway? I think what he means Gab, is that he's using a larger FOV, but it's causing distorsion at the egdes, which it shouldn't do. I thought you only got weird bending when you zoomed the camera IN. |
| ||
| The camera isn't involved in collisions. But the camera has to be inside the radius otherwise it can go slightly into walls, causing an ugly "see through" effect. To prevent this, I placed the camera inside the radius and zoomed it out. But this increased its FOV causing a problem I have illustrated below (though I can't make it look right when I post it): Normal FOV \ object / \0000000/ \ / \ / \ / Y camera Rendered to screen as: 0000000 Larger FOV \ _ object _/ \_ 0000000 _/ \_ _/ \_ _/ \ / Y camera Rendered to screen as: OO0o0OO Objects further from the center take up a larger percentage of the FOV than the center does. I anticipated this problem but solvig it wasn't easy (have you ever tried to put a drastically round surface on a square?). It still takes up too much memory though. |
| ||
| If the problem is that the camera is going slightly into walls perhaps adjusting CameraRange() so that the near value is smaller could help. |
| ||
| Already tried, small objects the character runs over disappear when they get close to the camera. Some sort of formula is the best option. |
| ||
| Ah right, now I get you. The problem is with the camera intersecting the level geometry. Well I would tend towards making the camera more dynamic, leaving it a good distance away and then only moving it closer to the character when it intersects a wall. So you don't have to change the FOV, most of the time it's exactly where you want, but the player only gets a close-up view when there is no alternative. Of course, doing this would mean you would need to hack some kind of no-response collisions because you would want to *know* when the camera was intersecting but not actually have a collision response ( because you're handling the response yourself. ) I'm not sure whether you would fancy that though, so I won't go digging around for ways of handling no-response collisions unless it sounds like something you would want to do. |
| ||
| small objects the character runs over disappear when they get close to the camera changing the near value of CameraRange to a small floating number might fix that (eg: CameraRange camera, .1,1000) |
| ||
| Avoid making the near camerarange value too small, as this can cause problems with the z-buffer. The z-buffer has much greater resolution up close than it does far away, and this resolution is based on the relative distance ratios between the the near and far clipping planes and the camera. If you decrease the near clipping distance too much, you can dramatically increase the amount of work that the z-buffer has to do. To get an idea of how third person cameras are done you might want to take a look at the Castle demo in the Blitz3D 3D samples folder ( C:\Program Files\Blitz3D\Samples\Blitz 3D Samples\mak\castle ). Essentially, the camera has its own collision sphere which has the same, or greater, radius as the near clipping range of the camera. You will still get situations where the camera sees through things, though. Sometimes the third person camera just gets caught between a rock and a hard place, so to speak. Also, if you want a normall looking camera focus, I recommend a CameraZoom setting of 1.6. |
| ||
| I don't thint I was properly understood when I told you that I already tried the CameraRange option. I had the same problem as before AND have the problem with running over small objects. Because all of the players are in the same building, even if the camera sees through things in only one place it allows the players to cheat. I also want to keep the camera in the same place relative to the character which rules out moving it when it encounters a wall. The "screen" I've been using works perfectly, but it takes up way too many resources (you can easily see the fps difference when it isn't in use). It works simply by scaling the pixles along the outside more than the pixles toward the center. It's simple, but hard to write an equation to substitute. The other options just don't work right. As strange as it sounds, Blitz probrably has a similar system built in because the viewing area increases the farther away it is from the camera. If the cameras unrealistically looked strictly ahead, this wouldn't be a problem. |
| ||
| There is no way around CameraRange. Imagine your camera was the head of a person. YOu can't put your head into the wall, but you can get pretty close to the wall with your eyes. Depending on the level scale you may have to allow distances down to about 2 inches, or about 5 cm. If one BlitzUntit is one meter then this would mean a camera start range of 0.05. If your level is scaled even smaller , then it may be even less than that. CameraZoom is doing a completely diffrent job. So you need both, a low camera start range and a collision mode for your camera that prevents the camera from dipping into a wall. |
| ||
| Easy but poor method - if you don't want the camera to alter the distance between itself and the player, but don't want it to show what is on the other side of a wall - linepick from the player to the camera and if the linepick picks an obstacle, like a level, set the cameraprojmode to 0 to basically present a black screen. Not pretty but will do what you have said. Then set the cameraprojmode back to 1 when the linepick does not strike an object between the player and the camera. |
| ||
| I use CameraRange Camera, 0.1, 4000 It's always worked for me. |
| ||
| The problem isn't in first person mode but in third person mode. This makes it more difficult. You can't simply put the camera inside the character's head. This demands a fairly high CameraRange minimum parameter (in my case, about 100). However, if I do that, you can see through a object simply next to him. To fix that, you need to set the CameraRange parameter to be quite low. This results in being able to see through objects just behind him (as well as an unusual predicament). As you can see, in my case, adjusting the CameraRange results in a frustrating paradox. P.S. Does anyone know the ratio that the FOV diverges to the distance from the camera? If I knew that, then I could probrably adjust the CameraRange in conjunction with looking down at the character a slight amount and know the minimum limit this amount could be. |
| ||
| After trying to fix this problem for months, I have finally decided that solving this problem is far more difficult than it originally appeared. The only goodlooking and effective method I have seen so far has been the screen, which in itself takes up at least half of my computers CPU power (not to mention the size of the 3D world). Therefore, I have reluctantly decided to stop investigating until a later date. I will still happily accept any suggestions on this problem. If it helps I discovered that setting the cameraprojmode to 2 completely eliminates the problem, but also throws all perspective out the window (because it eliminates the divergence of the FOV). Thanks for all your help. |
| ||
| Why not have the camera collide with the surroundings? That way you can force it back until it collides with something. OR, have the smaller rooms equipted with a pivot, which show the best camera position in that room in order to see it all, and move the camera there. As you say, it's not an easy problem to get around, impossible sometimes. I suppose you could help by improving the level design so there are no really small rooms. |
| ||
| The problem is more profound in hallways as opposed to small rooms. As you say, moving the camera around would be an easier fix. But this is a shooting game, and moving the camera makes aiming nearly impossible. For now I am just using it in first person mode. How exectly do Blitz3D cameras work? Does anyone know what kind of formula they use to get the image? |
| ||
| How do you mean? I think what you need is clipping planes. Clip the hallway behind the camera, bring the camera back, so the camera can see into the hallway from the outside, but not see the room it has forced itself in. The FASTLIB extensions library can do this. Barring that, you hide any rooms + enemies that lie behind the camera and bring the camera through the wall. |
| ||
| Huh? My problem is that the camera can intersect other meshes, so you can see through them. I need to keep the camera in the same place relative to the player so that he can aim. I doubt clipping would fix this (the game is multiplayer too). Initially I tried to fix this by setting CameraZoom to 0.2 but, while it widened the view, it caused distortion, which I have found almost impossible to fix. Take a look at my code archives entry to see what I mean. |
| ||
| Well clip planes would fix what you suggest. It would allow the camera to go through the wall behind the player, whilst not showing what is on the other end of the wall, whilst allowing the player to get a good aim. It really is the only way your going to give the player a decent view of whats going on. |
| ||
| arent clip planes same as Camerarange? |
| ||
| Not really. You could place a clip plane 5 units in front of the camera and rotate it 45 degrees. You couldn't do that with camera range. Basically if you put a clip plane across the line of the wall, then anything behind that wall wouldn't get drawn. You can place them anywhere. I think the FAST extend library only supports 6 of them? http://www.whiterockscience.com/moritz/clip.html You couldn't do that with camerarange. |
| ||
| oh..you mean they are not attached to the camera?? |
| ||
| Nope :o) It's like rendering a scene and cutting out a section of it. |
| ||
| I'm kind of confused with this clipping plane concept, but I have tried several variants of CameraRange, none of which worked. Basically, even though the front range of the camera has been moved up, that view still intersects objects. I think I get what you mean with the clipping planes and will look into it. I see how it would fix it but won't it cause other problems? Wouldn't it keep the character in the same position on the screen and clip out the unwanted view, but get closer to the character when the clipping is needed, starting my camerazoom problem again? I would post a diagram showng what I mean but if you look above you'll see that it may not be any good. |
| ||
| Well you can dynamically move clipping planes, so technically, you can do what you want with them. I'm not sure what you mean though. |
| ||
| I'm afraid I can't post an example of what I mean and have it make any sense. However, I have been trying to move the camera like in the castle demo for a month without success. Blitz doesn't seem to recognize that the camera (or a pivot, I've tried it both ways) is colliding, even though all the collisions are set up. I'm having a similar problem in a simple physics engine I'm writing: the objects slide off one another, but when I use countcollisions() to try to detect a collision to calculate friction, a collision is never registered. I believe that moving the camera will be faster than clipping planes and look pretty good, but if I can't detect collisions, I can't tell the camera how to move. Has anyone experienced this before, and is it a b3d bug? P.S. Both of these occurences happen in functions, but the castle's chasecam is a function too. |
   |