Perspective Correct Texture mapping with Direct3D 9

Started by
4 comments, last by peakhunt 19 years, 2 months ago
Please! HELP WANTED. As a hobbyst game programmer, I'm working on a simple skybox implementation. But problem is without perspective correct texture mapping, the distortion rate is so high that it's almost unacceptable. So with my software based rasterizer, I tried perspective correct( inverse U/V interpolation) texture mapping and it just looks so perfect. Now problem is I don't know how to set up 3D H/W to use perspective correct texture mapping through Direct3D 9. Please don't ask why I'm not using Direct3D cube map. I just want to implement in this way. PLEASE HELP! and as always, thanks in advance.
Advertisement
Not sure I understand the question.

The D3DPTEXTURECAPS_PERSPECTIVE member of D3DCAPS9 tells you if perspective-correct textuing is supported.

If it's supported, I'm almost certain it's enabled automatically, whichever texture type you use.

Are you trying to use Direct3D instead of your software rasteriser, or something else?

-Mezz
Thanks for your reply.

Actually I just read the same thing on Direct3D documentation and I checked whether my H/W supports perspective correct texture mapping.

OK. Here is my situation. Acutally I developed a totally software based 3D engine. And after the completion, you know, performance sucks. So I decided to adotop only H/W rasterization part. So local to world, world to camera, lighting, 3D clipping, perspective projection, and transformation to screen coordinate are done with my S/W engine code. After that I set up direct x vertex buffer, blah blah blha... you know.

It looks like this problem has something to do with my 3D clipping code. I mean, something doesn't match with H/W rasterizer when it comes to 3D clipping.

Again thanks for you reply.
That's cool, I have just one last suggestion then - are you you're using D3D_XYZRHW in your vertex format? You'll need to if everything is being transformed etc. by you.

-Mezz
yes, I guess U almost got it.
I'm using XYZRHW and it looks like RHW(reciprocal of homogeneous w , what the heck ;-)) is causing some problem here.

Currently I'm using d/z as RHW, where d is distance to the viewport and
z is z value of a vertex.
But still, it doesn't work and I'm getting some strange effect.

But when I use 1.0f as RHW, it just looks a little better but distortion rate is still high.

Actually in my case, considering aspect ratio, using d/z as rhw doesn't make much sense. But I think if driver is using RHW for u/z v/z interporation, there shoould be much problem. Anyway, I'm completely lost here and desperately looking for documents and experiences here.

Any suggestion or experience on setting RHW for already transformed and lit vertices?

Thanks.
OK. I guess I know why this problem was happening.

First of all, for RHW, giving 1/z as RHW is correct and it's pretty logical. And if I give 1.0f as RHW, I get perspective correct texture mapping problem.

I guess my 3D clipping code caused this problem. So I changed to S/W vertex processing mode and enabled clipping and the problem was gone.

The real problem was "my 3D clipping code handles only near_z case." For other cases(left, right, top, bottom, farz frustrum clipping), my S/W rasterizer handles the case since it's easier than 3D clipping. It looks like DirectX and compatible H/Ws require clipping on those planes too.(But I'm still not sure since small triangles look stiil good without full clipping).

Anyway, oh my god, I have to implement clipping all those planes...
And just for reference, here is DirectX documentation for this part.

======================================
Direct3D does not clip transformed vertices of a primitive from a vertex buffer unless it comes from IDirect3DDevice9::ProcessVertices. If you are doing your own transforms and need Direct3D to do the clipping, you should not use vertex buffers. In this case, the application traverses the data to transform it. Direct3D traverses the data a second time to clip it, and then the driver renders the data, which is inefficient. So, if the application transforms the data, is should also clip the data.

When the device receives pre-transformed and lit vertices (T&L vertices) that need to be clipped, in order to perform the clipping operation the vertices are back-transformed to the clipping space using the vertex's reciprocal homogeneous w (RHW) and the viewport information. Clipping is then performed. Not all devices are capable of performing this back-transform in order to clip T&L vertices.

The D3DPMISCCAPS_CLIPTLVERTS device capability indicates whether the device is capable of clipping T&L vertices. If this capability is not set, the application is responsible for clipping the T&L vertices that it intends to send down to the device to be rendered. The device is always capable of clipping T&L vertices in the software vertex processing mode (regardless of whether the device is created in the software vertex processing mode, or switched to the software vertex processing mode).
======================================

And after I finish implementing clipping code again all the other frustrum planes, I'll write the result of my experimentation so that we can share knowledge from my humble experimentation.

Thanks.

This topic is closed to new replies.

Advertisement