Z-Buffer precision - some artifacts

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Z-Buffer precision - some artifacts

Post by anmabagima »

Hi there,

I'm playing around with 3D objects in my homebrew. Unfortunately some objects are very close to each other or overlapping which causes some strange behavior during rendering. I would have assumed this is due to the precision of the Z Buffer. However I've set the maximum depth range with sceGuDepthRange(0xffff, 0x0);

As it is very difficult to describe the behavior I'm attaching some images.
Image Image Image

In addition to that I've recognised that if you are drawing objects with transparency it seem to be importand that you call the draw methods for the objects in the right Z-Order (from back to front) as otherwise there will be nothing visible beyond the transparent object. Is this a "bug" or function as designed, as I would find it a bit strange that I need to sort my objects in the right Z-order on my own before passing to GU for rendering to enabke full transparency function ?
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

I think you want to set the depth range to be smaller so that the precision of the zbuffer is spread over the range of zs that you actually use. I'm not sure how that gu call affects the rendering, but if setting the range much smaller doesn't help, then you can always fix the view matrices to scale it for you. That should stop some of the 'poke-through' or 'z-fighting' which is a well known rendering artifact of zbuffers.

Jim
User avatar
Raphael
Posts: 646
Joined: Tue Jan 17, 2006 4:54 pm
Location: Germany
Contact:

Re: Z-Buffer precision - some artifacts

Post by Raphael »

anmabagima wrote:Hi there,
In addition to that I've recognised that if you are drawing objects with transparency it seem to be importand that you call the draw methods for the objects in the right Z-Order (from back to front) as otherwise there will be nothing visible beyond the transparent object. Is this a "bug" or function as designed, as I would find it a bit strange that I need to sort my objects in the right Z-order on my own before passing to GU for rendering to enabke full transparency function ?
That's as designed, because the depth buffer doesn't (and cannot) know about transparency. Normally, you just disable depth writing when rendering transparent polygons as last polys in the scene, but keep depth testing enabled.

Either that or you z-order your polys (the transparent polys themself should be z-orderer anyway to get right rendering, because blending is generally order dependent).
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki

Alexander Berl
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi there,

thanks for your replies. Dam, I have assumed this but have hoped that I can do something.

@Jim: If I decrease the depth range to smaller value the "poke-through" is much more strange. However, what do you mean by
then you can always fix the view matrices to scale it for you
Usually I would use an identity matrix for my View. What should this look like ? Just an adopted value for the z component of the z part of the matrix ?
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

It looks like all your post transform z values are really, really close together, causing a lack of precision in the z buffer. If they have enough precision before transformation i.e.your model isn't stupid, then use the z component of the matrix to stop all the zs landing on top of each other.

Jim
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi Jim,

I'm still not sure whether I get you right or not ... sorry..

My model is loaded from an external 3D Modeling tool into the GU kind of handling 3D object within a mesh. However, as the modeling tool does not provide you with a functionality of placing your objects to a grid of say 0.0001f precision it could be that the z-values of the faces of two close objects are different on the 8th or tenth diget after the dot (0.000000001)... does GU can't handle this ? However, this I could try to avoid in setting my 3D model as best as possible befor releasing the homwbrew ;o).

But there are objects which - fore some reason - are overlapping. The "touch point" of such faces should be a line how precice the single vertices of the mesh of the object are , right ? As the faces overlapping are more or less "big" - meaning does contain of only 1 or 2 triangle - could the splitting into smaller triangles solve the issues ?

Getting your comment right I would assume that I should not use

Code: Select all

sceGumMatrixMode&#40;GU_VIEW&#41;;
sceGumLoadIdentity&#40;&#41;;
but change the z-component of the View Matrix - right ?

Thanks for your thoughts
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

z-values of the faces of two close objects are different on the 8th or tenth diget after the dot (0.000000001)... does GU can't handle this
Of course not, that's 1 part in a billion, the zbuffer is only 16bits, less than one part in 100,000. You need to spread your minz to maxz range across the 16 bit scale. If you tell the psp near z is 0 and far z is 0xffff and then you give it all zs in the range 0.000000001 -> 0x000000002 then all your vertices will be in the z=0 box and everything will poke through. If you tell the psp your vertices are in the range 0->0x000000002 then your vertices will span the 16bit range. Now, I do not know if you can set the psp to do that logic for you, I would have thought that gu call would help you, but only if your objects had sane zs, which they don't. You may need to scale your objects so the zs are in the kind of range the psp can discern.

Once your objects are transformed, what's the minz and maxz?

Jim
davidgf
Posts: 21
Joined: Mon Aug 31, 2009 10:05 pm

Post by davidgf »

I use OpenGL, don't use GU, but there's one moment when you define your projection matrix (gluPerspective).

So the near plane should be far enough and the far plane close enough. Pushing the near plane a little away should avoid Z fighting.

You can paste your code if you want more info.

Rendering transparent surfaces is a big pain always. Only in PCs using Pixel Shaders is easier. The solution is rendering the solid trinagles, then the transparent triangles. But if you have something like a corridor of glass dors (like Star Wars) you have to render the transparent objects in the right order.
If those triangles intersect each other you'd better shoot yourself... It's like impossible ;) Some hardware like Dreamcast doesn't have this problem (PVR graphics adapter).

Hope it helps
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi again,

thanks for your valuable inputs...
Once your objects are transformed, what's the minz and maxz?
The minz is 0.05787 and the maxz is -89.91268 in worldspace coordinates and assuming the view is along the negative z axis....

My projection matrix initially was set to 0.1f near and 1000.0f far.
I've changed this to 1.0f near and 400.0f far. Does this intend that objects are clipped at the far and near plane ? So I need to be careful not having objects more far away than 400.0f

However, changing the parameters for near and far of the projection matrix pretty much increased the quality of the rendering for me.

Thanks to you guys....
davidgf
Posts: 21
Joined: Mon Aug 31, 2009 10:05 pm

Post by davidgf »

Of course! Every polygon gets clipped at the near and far plane. Have you realised that fog in some computer games? It's just to avoid the user to see the objects disappear or get sliced at the far plane. The near plane is not a problem, just maintain your camera away from objects.

If you do shadowing or more complex techniques that is a problem, but in a common scenario the projection matrix isn't a problem.
Post Reply