Jump to content

  • Log In with Google      Sign In   
  • Create Account


neeker

Member Since 11 Jul 2013
Offline Last Active Sep 19 2014 02:49 PM

Posts I've Made

In Topic: Stencil Buffer

04 September 2014 - 12:55 PM


Stencil zfail is for when both depth and stencil fail, and again it doesn't affect what gets drawn but rather what happens to the values currently in the stencil buffer.

 

MSDN says zfail is for when the stencil passes but depth fails.  Is this correct?

 

Anyways, what I want to accomplish (going back to the first post) is for the terrain pixels inside the cardboard box to be discarded.  If there are terrain pixels in between the camera and the box top, they need to be rendered (this is currently where I'm struggling).  If terrain pixels behind the box get discarded, that's fine because the box would over write them anyway.  I hope that makes things a little more clear?


In Topic: Stencil Buffer

04 September 2014 - 12:13 PM

For the second pass, you want to draw everywhere that the "mask" wasn't drawn

 

This isn't quite what I want.  I need to draw everywhere that the "mask" failed the depth test.  For instance, there may be terrain in between the camera and the "mask" that should be drawn.  I was assuming this is what the D3DRS_STENCILZFAIL op was for, but it doesn't seem to be working how I expected it to.


In Topic: Stencil Buffer

03 September 2014 - 05:21 PM

Give D3DCMP_GREATER a try for the stencil func.

 

I've tried this and the opposite affect occurs.  I.e. The terrain is rendered everywhere except for the stencil mask, which is always not rendered (everything is always rendered with D3DCMP_GREATEREQUAL).  So, that would seem to point to my pass/fail/zfail settings, but changes to those do not do anything at all.


In Topic: atan2 inconsistencies

19 March 2014 - 02:19 PM

atan2() does not dice ;) It is probable that the values shown by Logf() are rounded when being displayed, i.e. not all significant bits are shown. You may try to enhance the output resolution, or try to output the values as layered uint32_t like in

    *(static_cast<uint32_t*>( &vEyePosition.x))

to see whether they differ.

 

The expected minimal difference in the values then cause a minimal positive or negative value, resp., what then means 0° or 180°, resp.

 

This is a typical problem with differences of floating point numbers.

 

Good idea with the casting; that revealed that there are (very slight) differences.


In Topic: atan2 inconsistencies

19 March 2014 - 01:32 PM

   Logf("vEyePosition = %g, %g, %g", vEyePosition.x, vEyePosition.y, vEyePosition.z);
   Logf("vStartLookAt = %g, %g, %g", vStartLookAt.x, vStartLookAt.y, vStartLookAt.z);
   fViewRotY = atan2(vEyePosition.y - vStartLookAt.y, vStartLookAt.z - vEyePosition.z);
   fViewRotX =atan2(vStartLookAt.x - vEyePosition.x, vStartLookAt.z - vEyePosition.z);
   Logf("Post fVeiwRotX = %g", fViewRotX);

The log messages are:

 

vEyePosition = 1.57361e-007, 50, 9.7
vStartLookAt = 1.57361e-007, 0, 9.7
fVeiwRotX = -9.68575e-008

 

...and...

 

vEyePosition = 1.57361e-007, 50, 9.7
vStartLookAt = 1.57361e-007, 0, 9.7
fVeiwRotX = 3.14159

respectively. 
 


PARTNERS