wondering about the Z-buffer

Discuss RCP-related matter here.
Post Reply
User avatar
Mizox
Posts: 17
Joined: Fri Oct 04, 2013 8:24 pm

wondering about the Z-buffer

Post by Mizox » Mon Jan 27, 2014 3:40 pm

I'm assuming the N64 used something analogous to the modern Z-buffer. where there is a linear (or quadratic or whatever) function which applies Z-values to geometry and then the rendered pixels in order to help with clipping and culling and fog and so on

correct me if I'm wrong about the above though... I really only dabble in looking things up ^^;

so anyway. I was wondering if it would be possible to pass those values through to the final opengl frame buffer before displaying. and in doing so allow people to write post-processing shaders that use them (ssao. ssaa. etc)

I know the RCP code isn't really a priority right now (and neither is any post processing or whatever). I'm just curious for future reference

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: wondering about the Z-buffer

Post by MarathonMan » Mon Jan 27, 2014 8:55 pm

Yes, there is a z-buffer... however, it sucked so much of the already constrained power of the RDP that many times developers did sorting prior to rendering I believe.

I'm not really all too familiar with the MESS graphics core that CEN64 is currently using, so that's all I have to say for now.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: wondering about the Z-buffer

Post by Narann » Fri Jul 25, 2014 10:18 am

Sorry for the late answer:
MarathonMan wrote:Yes, there is a z-buffer... however, it sucked so much of the already constrained power of the RDP that many times developers did sorting prior to rendering I believe.
Actually most (all?) N64 3d games overuse z-buffer write operation (z-buffer update). Maybe devs tried to avoid it as much as possible but depth sorting is very difficult (sometime impossible) to handle in a smart way.

The only game I've seen that handle the z-buffer "smartly" is Super Smash Bros 64. Of course, it's because the triangle positions are predictable. The whole scene is rendered using depth sorting (no z-buffer update, triangles are drawn from back to front) and the only part with z-buffer write operations is the "slider" area with characters (aka, the "part you have no choice"). I guess every versus fighting game deal with depth write like this and I also guess it's the good way.

This is one of the reason this game was so fast and have a such impressive framerate.

IIRC, Mario Kart 64 also don't write z-buffer with ballons at the start of the race (but as you can see, it's a limited effect).

And last: Even on modern GPUs, "manual" write on the depth buffer is performance disaster as if you choose to do so, drivers can't optimize the working doing the early depth test "before" the shading (and choose to skip some triangles).

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: wondering about the Z-buffer

Post by MarathonMan » Fri Jul 25, 2014 10:27 am

Indiana Jones and the Infernal Machine didn't use the Z-buffer in their ucodes. Probably one of the reasons why the game could run at full resolution and look so good. I believe World Driver Championship and Stunt Racer 64 also did not use the Z-buffer per Factor 5's ucodes.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: wondering about the Z-buffer

Post by Narann » Fri Jul 25, 2014 2:28 pm

MarathonMan wrote:Indiana Jones and the Infernal Machine didn't use the Z-buffer in their ucodes. Probably one of the reasons why the game could run at full resolution and look so good. I believe World Driver Championship and Stunt Racer 64 also did not use the Z-buffer per Factor 5's ucodes.
Maybe all this ucodes are related to a custom "hand shaped" z-buffer? I don't see how it's possible to have complex 3d model rasterization without depth testing (something new to learn today).

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: wondering about the Z-buffer

Post by MarathonMan » Fri Jul 25, 2014 3:02 pm

Well if you draw the objects furthest away first, there's no need for a Z-buffer because all the triangles will just overlap in the correct order. ;)

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: wondering about the Z-buffer

Post by Narann » Fri Jul 25, 2014 3:26 pm

Yes, like the Super Smash Bros 64 example, but in the case of interpenetrating triangles you need a per pixel depth testing (like the Super Smash Bros 64 example :D ).

User avatar
bsmiles32
Posts: 8
Joined: Tue Jul 29, 2014 1:58 pm

Re: wondering about the Z-buffer

Post by bsmiles32 » Wed Jul 30, 2014 2:08 am

I believe World Driver Championship and Stunt Racer 64 also did not use the Z-buffer
I can confirm this. Both games use the same ucode, and this ucode only emits shaded/textured triangles/quads. So no Z-Buffer for them.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: wondering about the Z-buffer

Post by Narann » Wed Jul 30, 2014 9:26 am

bsmiles32 wrote:I can confirm this. Both games use the same ucode, and this ucode only emits shaded/textured triangles/quads. So no Z-Buffer for them.
Hi bsmile32! Nice to see you here! :)
As you dig into HLE, do you know how the RaSterizer deal with interpenetrating triangles without z-buffer? I'm very interested actually. Maybe this games write a "hand made depth-buffer" framebuffer on "area of potential interpenetration" (see Irregular Z-buffer) and use this to choice the triangle one the CPU? Any further info on this is welcome! :)

User avatar
bsmiles32
Posts: 8
Joined: Tue Jul 29, 2014 1:58 pm

Re: wondering about the Z-buffer

Post by bsmiles32 » Wed Jul 30, 2014 2:01 pm

From my limited reverse engineering effort, it seems that this ucode has similarities with the so called "zsort" ucode.
Basically the CPU sort each primitive by their depth (or any criterion that does the job), and the RSP converts this ordered list of primitives into a suitable RDP list
(ie Shaded and/or Textured Triangles / Quads). Since there is no Z-Buffer, the RDP draws everything and skip the Z-test altogether.

From my understanding this approach works well if your primitives don't cross in weird ways (ie cannot be ordered by depth). But with suitable decomposition
(split the primitives to make them orderable again), there should be no problem.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: wondering about the Z-buffer

Post by Narann » Thu Jul 31, 2014 9:23 am

Thanks! So it seems to be like I was thinking.
bsmiles32 wrote:From my understanding this approach works well if your primitives don't cross in weird ways (ie cannot be ordered by depth).
I understood like this too.
bsmiles32 wrote:But with suitable decomposition (split the primitives to make them orderable again), there should be no problem.
Good point! So the solution could be to detect interpenetrating primitives, split them, reorder, detect, and repeat of this maybe two-three times. And all of this just to don't use z-buffer! I couldn't imagine the z-buffer was so performance greedy that a such technic could make things faster.

I will try to see Indiana Johns, World Driver Championship and Stunt Racer 64 videos to see if I can recognize such effect. :)

Thanks again!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest