CameraRange Problem
Blitz3D Forums/Blitz3D Programming/CameraRange Problem
| ||
| I have a serious problem with CameraRange: My fps gunhand is scaled down to a very small size to prevent it from dipping into walls. I prefere this over the not-working EntityOrder hack. To make this work, my camera range needs to start at 0.03 (to eg. 250). This is all working fine so far. Now I have a level mesh that contains some hills from a FLE export (ALE like terrain mesh, using vertex alpha). The Mesh is using a slightly z-elevated alphablended mesh for the additional materials, i hope you know what I mean. (This kind of "blending" isn't very clever anyway, but for this level I don't want/can go back) Where this renders fine with a camerarange min of 0.1, it starts z-fighting horribly with a min of only 0.03. But when I use a min of 0.1 then the gunhand mesh is rendered only partly. How you solve this Problem? I would like to prevent an additional render because of the overhead and also to keep things simple. |
| ||
| I'd be surprised if an additional render would cause much of an overhead. Afterall, you're only rendering the same amount of objects, just in 2 render passes. Have you tried it? Other than doing something like this, I can't see how you can get this working with a near clip of only 0.03. Maybe try a w-buffer? |
| ||
| Thanks. WBuffer is already on. I couldn't find an other solution than the 2nd renderpass. One is rendering 0.25 to 450 and the other one 0.03 to 0.25. This works ok. I only remember Halo reported speed loss trough renderworld overhead some time ago, an empty renderword would still eat a few millisecs. It still has to iterate trough all meshes and see if they intersect the current camerarange, regardless if they were already rendered in the prev pass. At least I made it optional. The camera cfg file allows to turn on/off this 2nd pass, as well as to define the ranges of both passes. So it's "undoable". |
| ||
| Heres a really bad idea... try altering the camerazoom value slightly keeping the 0.1 on the camerarange and move the gun mesh away slightly. |
| ||
| One is rendering 0.25 to 450 and the other one 0.03 to 0.25. That seems an odd faff when you can just bung in a second camera, miles away, and composite the gunhand with that. |
| ||
| That would be two renders too, so it doesn't really matter. The gunhand is also "cross-woven" in the current location, eg: it's lit by local lights etc. For now the two part render is ok. It's also a future feature to prevent z-resolution problems based on rounding errors. Thanks everybody. |
| ||
| its not that bad. i am also using the 2 pass method. it gave me better quality (less z-fighting or higher viewdistance) than a one pass render. i am using hud&gun as second renderpass btw. so there's not really a loss in speed... |
| ||
| Thanks. I also prefere this higher flexibility of the Z-Buffer, the ability to prevent z-fighting. Additionally, the level design allows to define the ranges and to skip the 2nd pass, so everything's fine. I still wonder why my HUD is rendered with the distant pass - maybe cause it's using EntityOrder infrontofeverythingelse. |
| ||
| I've posted this a million times before, but someone might find it useful: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html ..really shows you why z-buffer is such a big problem with close distances. |
| ||
| ^^ Yep. Should be compulsory reading. Although, I'm sure jfk knows all about this, already. :) |
   |