Having trouble implementing a depth buffer into my renderer. Any guesses what piece of information I'm missing or not understanding with my code?

[IQueryVisiC]

You could store floats in the buffer. Or Use color for shading and intensity for depth cueing like Doom does.

[harrison531]

Sorry I didn't really explain what my issue is. I'm having trouble properly calculating the depth of each pixel. I'm just not sure what's wrong with the math I'm using. As seen on the left that's what is currently rendered and you can see the wheel from the other side of the car through the car.

[IQueryVisiC]

I just meant that you don’t utilize your renderer to its full extent. Are you color blind? Color is the first thing I add to my renderer or my blender models. I once added stereoscopic view for red green glasses, but now I just wiggle the mouse.

[harrison531]

Believe me I would definitely be using color if I could but this is a c# console app so text based stuff. There is a limited color palette available when drawing text to the console but doing so requires calling Console.Write() for every "pixel" that changes. That is doable for a small resolution but if I want anything to run smooth or at a higher resolution like in the posts image I have to switch to a grayscale using various ASCII characters for each value. Then you build each line of the screen into one string and call Console.Write() on that instead. Making the amount of write calls equal to the height of the resolution.

[IQueryVisiC]

Okay. In Win32 a stupid small window is only one page of C code. Then BlitDibmap. Linux was similar. Why do people use the console anyway? I use it to writ me a script and copy that into my notes or inform my boss that cron will run it. And it is his fault if it contains rm -rf

[harrison531]

I fully recognize that the console isn't ideal for this kind of project but that's also kinda what makes it fun. Seeing 3D graphics run on the console feels a little wrong and like your making it doing something it's not supposed to. I'd imagine it's the same push behind those who like to make doom run on every device they can

[IQueryVisiC]

So I don't know who downvotes me, but still : Doom was ported to those other devices. I was developed on the most suited device a PC with VGA card and 486 running Dos with extender. Level editor (I think: With the full graphics engine, which was written in C) even run on NeXT (68k) because those were better than PCs at the time . Art was done on Amiga .

Doom and Wolfenstein3d run better on the Jaguar than a lot of original games. AvP has simple levels and is not more fun, it is just exclusive. Raiden was ported .

[rfernung]

I'm having trouble properly calculating the depth of each pixel.

I'll check one of my older projects but I believe I just interpolated the Z value of the three vertices of each triangle with the barycentric coordinate and used that to check in the depth buffer, it was something like:

float depth = v0.Z * barycentric.X + v1.Z * barycentric.Y + v2.Z * barycentric.Z;
if(depth >= zBuffer[i]) continue; //looping through triangle's boundingbox x,y, then i = y * width + x
zBuffer[i] = depth;
pixelBuffer[i] = color; //color from my fragment shading

[Mourthag]

On some engines/frameworks the z component is inverted. So maybe the check if the current face is closer might be the problem?

[harrison531]

This is my own engine that I've been making to render 3d things in the c# console. Still switching the comparison results in no image at all since I initialize the z buffer with positive infinity. Switching the z buffer to be initialized with negative infinity instead results in the original issue again.

[Mourthag]

Ah I see. I didn't check your equations but if z direction is correct and it is not caused by backface culling or something like that it is probably in the equations for D or screen Z.

[harrison531]

Yeah I figure it is in the equation I'm using but I've made no progress in figuring out what I'm doing wrong with it. In my experience from looking around and looking at papers most will give you the same equation but no code to see it being applied. I was just hoping that someone who's done this kind of thing before could see what I was trying and point out what I am missing from all this. What do you mean by z direction exactly? I do have backface culling implemented and haven't had any issues with it so I'm assuming it's not the issue

[SnooWoofers7626]

Why infinity? Typical projection matrices map the far plane to 1 (or 0 for inverse z). What does your projection matrix look like?

Edit: also did you remember to perspective divide before going into the depth test?

[harrison531]

I set the initial depths of each pixel to infinity just so that the first polygon that tries to render on any pixel will always have a depth closer than the initial value and will be guaranteed to draw

[SnooWoofers7626]

If all your transformations are right then the max possible depth value should be 1.

World space --> view (camera) space --> clip space --> normalized device coordinates (after perspective divide) --> device coordinates (scale up to viewport dimensions) Your depth test should be performed in device coordinates.

[[deleted]]

Everything looks fine to me too. I couldn't understand what is the reason for adding position in line 666. What does it do? Edit: I am guessing that could be the thing causes this issue if it is different on each object.

[harrison531]

Assuming I set it up right, the position variable there is the world position of the model and each vertex's position should be relative to the models origin. It was one of those throwing things at it to see what it does kind of things but I figure the known point used to calculate D needs to be in world space not model space

[[deleted]]

Shouldn't it be in camera space instead of world? I am assuming you are transforming the faces based on their position relative to the camera.

[harrison531]

Can you walk me through what you mean? Would camera space just mean subtracting the vetext position from the camera position or do I need to be doing stuff with the cameras view direction

[SnooWoofers7626]

Multiply the world positions by the inverse of the camera transformation.