Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


swdever

Member Since 03 Mar 2013
Offline Last Active Nov 05 2013 02:13 AM

Posts I've Made

In Topic: Problem about vertex shader in Skybox

05 June 2013 - 09:07 PM

Interesting. I put that sample through PIX and yes, the behind-the-camera triangles don't get rasterized, even with cullmode = none. I think the reason is the clipping rules:

0 <= zc <= wc (clip space)

Behind the camera w (and so z) are negative, so get clipped.

Good job! This should be the right answer.Thank you!

In Topic: Problem about vertex shader in Skybox

05 June 2013 - 06:54 AM

Hey, culling will be performed based on the winding order of the vertices, so the back faces will still be culled correctly.

 

However, in the example you give, if you're using PosL as your cube-map lookup vector. You do not want to copy the w coordinate into that vectors z element.

 

You will want something more akin to:

 

 

    vout.PosH = mul(float4(vin.PosL, 1.0f), gWorldViewProj);
    vout.PosL = vin.PosL;
    vout.PosH.z = vout.PosH,w;

 

n!

Thank you for your answer. But the sample code,which I am studying, sets CullMode =  None. But the result is still perfect. After read you answer, I try to modify the code like this: CullMode = Front. Still the demo works well. Then I try to modify the code like this: CullMode = Back. This time, the skybox disappear. But other objects in my scene are rendered still. So I think maybe the CullMode isn't the key point in my problem.


In Topic: How does the pipeline know the index what it need when it draws a quad using...

03 April 2013 - 01:02 AM

http://www.gamedev.net/topic/586527-d3d11-geometry-shader-input-vertex-ordering/

 

So unless you provide adjacency information to your geometry shader, it appears to boil down to this value (http://msdn.microsoft.com/en-us/library/hh404489(v=vs.85).aspx):

 

FrontCounterClockwise

Type: BOOL

Specifies whether a triangle is front- or back-facing. If TRUE, a triangle will be considered front-facing if its vertices are counter-clockwise on the render target and considered back-facing if they are clockwise. If FALSE, the opposite is true.

 

http://www.gamedev.net/topic/586527-d3d11-geometry-shader-input-vertex-ordering/

 

So unless you provide adjacency information to your geometry shader, it appears to boil down to this value (http://msdn.microsoft.com/en-us/library/hh404489(v=vs.85).aspx):

 

FrontCounterClockwise

Type: BOOL

Specifies whether a triangle is front- or back-facing. If TRUE, a triangle will be considered front-facing if its vertices are counter-clockwise on the render target and considered back-facing if they are clockwise. If FALSE, the opposite is true.

 

http://www.gamedev.net/topic/586527-d3d11-geometry-shader-input-vertex-ordering/

 

So unless you provide adjacency information to your geometry shader, it appears to boil down to this value (http://msdn.microsoft.com/en-us/library/hh404489(v=vs.85).aspx):

 

FrontCounterClockwise

Type: BOOL

Specifies whether a triangle is front- or back-facing. If TRUE, a triangle will be considered front-facing if its vertices are counter-clockwise on the render target and considered back-facing if they are clockwise. If FALSE, the opposite is true.

 

http://www.gamedev.net/topic/586527-d3d11-geometry-shader-input-vertex-ordering/

 

So unless you provide adjacency information to your geometry shader, it appears to boil down to this value (http://msdn.microsoft.com/en-us/library/hh404489(v=vs.85).aspx):

 

FrontCounterClockwise

Type: BOOL

Specifies whether a triangle is front- or back-facing. If TRUE, a triangle will be considered front-facing if its vertices are counter-clockwise on the render target and considered back-facing if they are clockwise. If FALSE, the opposite is true.

  I think you don't understand what I have asked. Maybe it because of my poor English. But I found the first link you provided is useful. I have got a deep understand in the circumstance I have encountered. Thank you!


In Topic: How does the pipeline know the index what it need when it draws a quad using...

03 April 2013 - 12:51 AM

The triangles you output from the GS are not indexed at all, since there are no indices. Instead you output one or more triangle strips. The vertices that you append to a TriangleStream form a strip according to the standard rules for a triangle strip topology. To mark the end of a strip, you call RestartStrip. If you want to just output a triangle list you can do so by appending 3 vertices, calling RestartStrip, and then repeating.

So in the case of your quad output from the GS, if you append all 4 verts and then call RestartStrip your 2 triangles will be (v0, v1, v2) and (v1, v2, v3), which means the winding order will be clockwise.

   I'm sorry there is an error in the figure I provided. It's my fault. I have corrected it. If D3D uses the order you provided to draw, that is, (v0, v1, v2) for the first triangle and (v1, v2, v3) for the second triangle. Then the first triangle's winding order will be clockwise and the second triangle's will be counter-clockwise .

   I find the diagram of vertex ordering for primitive types in this link.

http://msdn.microsoft.com/en-us/library/bb205124%28v=VS.85%29.aspx

   Maybe using the standard rules, the two triangles will be (v0, v1, v2) and (v1, v3, v2)?


PARTNERS