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.

That seems an odd faff when you can just bung in a second camera, miles away, and composite the gunhand with that.

Graphics3D 800,600,0,2
SetBuffer BackBuffer()

sceneCam=CreateCamera() : PositionEntity sceneCam,0,5,0 : EntityType sceneCam,1 : CameraRange sceneCam,.1,100
handCam=CreateCamera() : CameraClsMode handCam,False,True : PositionEntity handCam,0,-10000,0

light=CreateLight() : PositionEntity light,200,200,-200

gun=CreateCube(handCam) : ScaleEntity gun,.1,.2,1 : PositionEntity gun,1.1,-.4,1 

earth=CreatePlane() : EntityColor earth,100,200,100 : EntityType earth,2
numBlocks=100
Dim block(numBlocks)
For i=0 To numBlocks
	block(i)=CreateCube()
	EntityColor block(i),100+Rand(0,155),100+Rand(0,155),100+Rand(0,155)
	ScaleEntity block(i),1,Rand(1,10),1
	While True
		PositionEntity block(i),Rand(-100,100),0,Rand(-100,100)
		If Not (Abs(EntityX(block(i)))<5) And (Abs(EntityZ(block(i)))<5) Then Exit
	Wend
	EntityType block(i),2
Next

Collisions 1,2,2,2

While Not KeyHit(1)

TranslateEntity sceneCam,0,-.1,0
If KeyDown(203) Then TurnEntity sceneCam,0,  1,0
If KeyDown(205) Then TurnEntity sceneCam,0, -1,0
If KeyDown(200) Then MoveEntity sceneCam,0,0, .1
If KeyDown(208) Then MoveEntity sceneCam,0,0,-.1
UpdateWorld

RenderWorld
Flip
Wend

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. :)