camera range error workaround...
Blitz3D Forums/Blitz3D Programming/camera range error workaround...
| ||
| I'm writing a flight sim with a 3d cockpit The problem I've run into is that specifying a camera range 'near' enough to render the inside of the cockpit- will create bad zbuffer errors in the outside scenery/buildings etc. The only workaround I have is to render just the cockpit with a near range (and black windows)- grab this as an image- then render just the outside- and then draw the masked cockpit image back on top of that. This works, but takes 6 times as long- mostly for the GrabImage command it seems... any bright ideas? many thanks in advance, I'll make the sim available when done.. |
| ||
| Rendering the cockpit to a separate camera would be the usual way. You'll have to use cameraclsmode on your main camera to stop it from clearing the color buffer (effectively turn off its built-in Cls). |
| ||
| There is also CopyRect instead of GrabImage. Then you could CopyRect the backbuffer to an image. I don't know if it's faster. |
| ||
| wow, I'd never noticed that command! every day's a school day... I'll give it a try, thanks! |
| ||
| Copyrect is good enough most of the time for realtime useage. But I reccomend using the method Gfk mentions. |
| ||
| You can also use entity order. Set an entity order of "-1" or less for your cockpit. The entire scene will be rendered, then the cockpit will be rendered last, overlaying everything. This way you can keep the camera-near at 1.0. |
| ||
ahh- satisfaction at last! separate short-range camera with it's Cls disabled works great- much faster one follow up- is there any way to simply disable a camera- i.e. for the outside only view? interestingly- setting it's range or viewport to 0,0 or very small actually seems to slow things down.... |
| ||
| That looks like a nice little project you've got going. How do you handle the floating point errors that creep in with coordinates at large values from 0? are you moving the whole world about 0,0,0? |
| ||
| HideEntity will 'turn off' a camera, as will CameraProjMode, iirc. |
| ||
| thanks Rroff, good question- I ran into that problem also- the world size is 200,000 x 200,000 - while the needles are fractions in front of the dials moving the world around the plane was too counterintuitive for my brain!, so I ended up moving the plane normally- then just re-centering the world around the plane- (and offsetting the plane) every few seconds a 2d cockpit would have been way easier- but I'm going for a more real experience-( including the nausea unfortunately!) |
| ||
| Gfk- I don't see any documentation for that command- but 0/1 turns it off and on and frees up time- thanks- I'm 12 millisecs per loop faster now so I'm good to go! |
| ||
| If you happen to need more juice, use EntityOrder. This would only use a single RenderWorld and would spare the second camera. I don't know how you were moving the world at first, but if you parent everything - except the plane - to a single pivot and move this pivot, you should get the same effect. |
| ||
| EntityOrder has its uses, but be aware that it will completely ruin any geometry that isn't perfectly convex (or perfectly concave and enclosing the camera. It not only takes the entity out of order but also disables proper ordering for the entity's individual polygons. I'm also not really seeing how it would help in this case... the natural ordering looks fine, this looks like strictly a range issue. |
| ||
| Yasha- yes, I toyed with entity order to try to fix the scenery zbuffer problem- but as you note - you can't apply it to anything that obstructs any part of itself -e.g. the terrain. kryzon- one RenderWorld seems to work for both cameras- and I found no difference in speed at all between one and two cameras rendering the same scene as long as they are working in two separate ranges-(1-50 and 50-50000) i.e. everything is still just rendered once? I'm basing all this on measuring the difference in millisecs() between the start and end of the main loop- just before the Flip, if that's the best way to track processing time? |
| ||
| The documentation for CameraProjMode says: 0: no projection - disables camera (faster than HideEntity) (1 is the default setting) Never tested it to see if its faster than hideentity tho. Only thing I've ever used entityorder on is for rendering stuff as a background and always behind everything else never had any sorting issues with that but its always been fairly simple stuff. |
| ||
| actually EntityOrder could be used here to enlarge the near range just by scaling up the cockpit (like *10,*10,*10) then up the near range to "1.0" or more But, I'm ok with Yasha for one point : EntityOrder does not like complex polygons and other point not mentionned : if you intend to use alpha/vertexalpha/texturealpha(or anything with alpha) entityorder will not sort the Z-Depth for the polygons and some backface will become visible or worse : the farvest polygons of the cockpit could be seen front of nearest ones so : modifying the cameraclsmode should be the best option Last edited 2012 |
| ||
| I've had the same problem and your suggestions are interesting to know thanks ! |
   |