Jump to content


Member Since 11 Jan 2002
Offline Last Active Yesterday, 08:44 AM

Topics I've Started

VFACE semantic in hlsl (SM3)

13 May 2014 - 11:57 AM


I've been trying to use the VFACE semantic to get different shading on the front and back side of my geometry. According to the D3D documentation, VFACE should be positive for frontfacing triangles and negative for backfacing triangles (I guess it would be more concise to say counterclockwise and clockwise?). I got it working in most scenarios. Only when textures are involved, it seems to fail (more precisely: I've got a batch of tests, and only the ones with textures are failing. What happens is that only one side of the geometry gets shaded, or both sides get shaded with the same material). I've been trying to pinpoint the problem, but without succes. In the case where it works, I get shader assembly code like this:

          def c0, 0, 1, 0, 0
          dcl vFace
   0:     cmp oC0.xz, vFace, c0.xyyw, c0.yyxw
   1:     mov oC0.yw, c0.xxzy

I don't know the instructions well, but this seems logical: in line 0 something different happens, based on the value of vFace. When I now take one of my shaders that use textures, I get this:

          def c8, -1, 1, 0, 0
          dcl_normal v0.xyz
          dcl_texcoord v1.xy
          dcl vFace
          dcl_2d s2
          dcl_2d s3
   0:     cmp r0.x, vFace, c8.x, c8.x
   1:     if_lt r0.x, c8.x
  24:     else
  45:     endif

That seems very wrong: c8.x gets stuffed in r0.x, no matter what value vFace has! In both cases, the hlsl code is something like:

    void main(in PS_INPUT Input, in float isBackFacing : VFACE, out PS_OUTPUT Output)
      Output.color = float4(0,0,0,1);
      if (isBackFacing < 0)

Am I misunderstanding this stuff? Are there things I should know about the interaction between VFACE and texturing? I really have no clue why this doesn't work, so any help is much appreciated smile.png

BTW: I check all calls into D3D, and have debug output at the highest level, but no errors are reported.

Multithreading, swapchains and Present()

05 April 2012 - 09:57 AM

In my (windows) application I want to render in a thread that is not the main gui thread. What would be the best way to 'share pictures' between two threads? My initial plan was to let the renderthread draw to d3d textures, and let the main thread blit the textures using a fullscreen quad. That would mean the renderthread has to wait while the main thread is drawing the fullscreen quad (as in: both threads should not be using the same direct3d device, even when it was created using the multithreading flag).

More context:
I'm writing rendercode for a cad-like application. It will be used to process lots of unstructured triangles. Rendering those takes some time (vertex data might not fit into video ram, multipass techniques are really slow on some hardware,...), but it should not 'block' the application. That's why all 'real' rendering is done on a second thread, and the main thread should only 'blit' (Present, fullscreen quad,...) the results to a window.
So whenever an application generates an event that should trigger a redraw, the renderthread will first draw a 'quick' approximation (using LOD, simpler techniques, or maybe even drawing bounding boxes or nothing at all...) for the application to show. Afterwards it will start rendering a slow high-quality image. To avoid flickering (because of always showing the 'quick' image) the main application thread will always wait some time (eg. 30Hz) before presenting the 'quick' image. If within that time the high-quality image is ready, the 'quick' image will be discarded.
The renderthread on the other hand should have the possibility to interrupt rendering the high-quality image. So that when lots of render requests arrive (eg. the user is interactively rotating the view) it can continuously generate the 'quick' frames for immediate feedback.

An alternative idea to avoid the render-to-texture-combined-with-fullscreen-quad approach is to create swapchains with one backbuffer. The quick image could be rendered directly to the backbuffer. The slow image is still rendered to texture, but the final stage would be to blit the slow image to the backbuffer. That way, the main thread only has to call Present() whenever it wants, and very little locking has to happen. Well, actually lots of locking has to happen, but it will be relatively simple, and the waiting will be limited. I would use a rendercommand queue approach where every rendercommand does some state setting and typically one draw call. Each one of those would then be locked separately, giving the main thread the opportunity to call Present() in between rendercommands.

Thanks for reading!

Garbage when clearing/rendering to texture

13 March 2012 - 11:54 AM

I'm implementing transparency using depth peeling. I have an implementation that works. But things start to fail when I resize my window. When I glClear my resized blended color texture (the one that stores the result of blending each consecutive peeled layer over the previous ones) before the first pass, It should become all black (alpha being 1.0). Instead it looks like this:

Posted Image

(the white/grey pattern was added by the tool I use to view the texture). Obviously this does not result in a correct final result :-)

Posted Image

I check for OpenGL errors after each single gl function call, but no errors are generated. My fbo's are complete, and when I use gDEBugger I can see that all textures/render targets have the same size. I have been looking into textures being attached to an fbo and a texture unit at the same time. I've been playing with the wrapping and mipmap settings to fix things. But I can't find the problem. Can anyone give me hints here? I would be very grateful!

[C++] pointer/reference to function/method

05 July 2010 - 03:20 AM

Apparently 'function references' exist in C++. The C++ Programming Language doesn't seem to explicitly state this, though. In Visual C++ 2005 and Comeau's online compiler, the following code compiles:

void DummyFunction() {}

typedef void (*TFunctionPointer)();
typedef void (&TFunctionReference)();

int main()
TFunctionPointer fp1 = DummyFunction;
TFunctionPointer fp2 = &DummyFunction;
TFunctionReference fr1 = DummyFunction;
TFunctionReference fr2 = *DummyFunction;


return 0;

You can see that you don't need the &-operator to get a function pointer. The C++ Programming Language says:.
The C++ Programming Language, 7.7 Pointer to Function
... That is, dereferencing of a pointer to function using * is optional. Similarly, using & to get the address of a function is optional...

Now I want to do the same thing for pointers to methods. Unfortunately, a 'reference to method' doesn't seem to be possible. The following code doesn't compile:

struct DummyStruct
void DummyMethod() {}

typedef void (DummyStruct::*TMethodPointer)(); //ok
typedef void (DummyStruct::&TMethodReference)(); //error

There is nothing that cannot be done with method pointers, but it would be nice to be able to have a method reference as parameter (for the same reason it's nice to be able to use normal references instead of pointers). Anybody any clue whether this is possible? Thanks!

[C++0x] "canonical" class - copy/move construction/assignment

19 April 2010 - 11:07 AM

Since VS2010 has some Cpp0x features implemented, I thought it was about time to start learning about them. Rvalue references will probably have the largest impact on how one should write classes. So I'm trying to find some "standard" way of implementing a class. Something that replaces "implement a non-throwing swap and implement assignment in function of copy construction". My current understanding leads to this:
class Foo
    State m_state; //assume State to be a 'canonical' class


    Foo(const Foo& other):

    Foo(Foo&& other):

    Foo& operator = (const Foo& other)
        Foo temp(other);
        *this = std::move(temp);
        return *this;

    Foo& operator = (Foo&& other)
        m_state = std::move(other.m_state);
        return *this;

Does that seem ok? The move constructor and move assignment are kindof doing the same thing, but any attempts to use swap to fix this have lead to infinite loops (as std::swap uses operator = (Type&&)). Is there a way to fix this? I'm also not too sure about my use of std::move and std::forward. Different texts seem to contradict each other on this issue. Any comments or links would be much appreciated.