So, I’m at a point where I want dynamic shadows, but the shadow example doesn’t work in DirectX, because panda’s directx pipeline doesn’t support depth textures, kind of a bummer. I would like to keep full DX support if possible.

rdb tells me I can achieve that kind of shadows in DirectX without depth textures, with shaders and normal textures, but at a performance cost. So I’m wondering if I should discard DirectX, keep DirectX but use shaders or add depth texture support to DirectX (which I would like to avoid very much because I’m clueless).

So, first, I would like to ask… Is there any technical reason that there isn’t support in DirectX of such a basic feature, or is it just historical? What kind of performance loss are we talking about for not using the depth buffer? And about adding depth texture support to DirectX, is it worth it? If my understanding of the whole thing is correct, by using normal textures I can do nifty things like realistically scattered shadows that I can’t do the depth buffer way, so I’m thinking that maybe it’s even better. Only thing I’m wondering about is the performance. So, your opinions on this?

Thanks as always.

There is no technical reason. The depth buffer support was added by CMU and by the community, not by Disney (we have more interest in supporting the very low end features, since our games are targeted at kids). The open source community tends to be more interested in supporting OpenGL, since that’s more universal, and less Microsofty. Also, our DirectX implementation is a bit of a mess, having been meddled around with by a series of short-term employees and interns over the years; and this tends to discourage further community contributions. Thus, Panda’s DirectX support tends to lag behind OpenGL in support of features specific to higher-end graphics cards.

This, I’m afraid, I have little experience with. Perhaps someone else can speak to this better.

That call is up to you. I think it would be swell to get our DirectX stuff up to Panda’s usual standards of quality, and that includes bringing its feature set up to match OpenGL’s. But as to whether this would help your project, I don’t know.


Thanks David. I was just asking in case there was a technical/architectural reason for it, since one of the options I’m considering is adding support for this, so I wanted to know what I was getting into.

I tried colormap as a method for shadows, and it’s only 3% slower. Also, incidentally DirectX is 15% faster than OpenGL doing shadows this way. (i’m talking of a simple scene). I’m still interested in adding depth texture support but I want to get this working for now, to have something, and I just have a minor problem now. I can project shadows over objects that are textured without shaders, with set_texture(something), but not over shaded objects, even though I’m handling the depthmap properly in the shaders of those objects.

I use the same system that the shadows demo, a caster.sha for the light cam and a shadow.sha for the main cam. For testing, I’m using the depthmap as output color. To the left you can see how it looks when the terrain is an object textured with set_texture(), to the right you can see how it looks when it’s textured with set_shader(). Notice that the depthmap is intact for the shadowed zones, but the lighted zones have been replaced by black, which is the clear_color, if I set the clear_color to purple, then I get purple instead of black. Also note how the shadow projected by the mountain in the terrain has disappeared to the right (self-shadowing issue?).

(Ignore the illogical shadows on the floating objects, I think the UV values are wrong or something. Also, I labeled the occluded zones’ colors, so that you realize they are the same colors, there’s an optical illusion there. And this is all OpenGL, although the same thing happens on DirectX)

Any ideas what could be causing the blackening of the light zones?

Edit: Updated with a new image that shows a self-shadowing problem.

Edit: This post has changed so much already… Let’s see, the blackening was due to a rogue set_clear_color I had somewhere that was setting it to black, if I remove it then I get the default 0.41% gray instead of black, so that black is just the clear color. If I set_clear_color_active(false) then I get stripes and artifacts. Changed the text to reflect this.

Fixed. rdb suggested increasing the priority on set_shader() and that did it. So, for reference, you’ve got to apply the casting shader like this:

lci.set_shader(Shader::load("caster-color.sha"), INT_MAX);