Horde3D

Hey guys.

Ok, I've got things coming along nicely. But I've hit a minor snagette.

I have NO idea how to specity that a material uses its alpha channel!

Specifically, I've got some trees in the scene as X's and need to obviously ditch the colour component using the alpha component.

Anyone care to enlighten me how that is achieved? I'm assuming its something in the material xml file?

Other than that, things are going pretty well since I moved to Horde. I'm just integrating Mikko Mononen's "Recast" navmesh API and then I'll be mostly functional. I'll post a screenshot or two once I figure out this alpha issue.

Seesya.

From your post I assume that you just want alpha testing (discard pixels based on alpha) and not transparency via alpha blending.

Alpha testing is done in the shaders with the GLSL discard instruction. You need to add something like this to all relevant shader contexts in model.shader:

This checks if the alpha of your diffuse map is smaller than a certain threshold and discards the pixel in that case. For performance reasons it is better not to use the discard instruction when it is not required. Alpha test/fragment discard can disable parts of the GPU's early z rejection. So the better way is to create a new shader combination like this:

To use alpha testing for a material, just set the corresponding shader flag in the material file (_F05_AlphaTest in the sample above). However, if you have no idea what I'm talking about , just ignore the performance part and go for the first solution. If you don't optimize your rendering for early and hierarchical z rejection (z prepass, depth sorting, etc.) you probably won't notice a difference.

Ah ok, so its not a feature thats currently implemented. Ok, no problem then. I'm assuming the if statement in the shader will make it SM3 only? (I'm not sure of myself with GLSL, but isnt branching a SM3 feature?)

Anyway, thanks for the response. Should post a screenshot soon.

The other issue is the shadow map. It needs to have the alpha mask of the tree texture to be able to do a rejection of that particular pixel when writing to the shadow map. Is there an easy way to do that?

Dynamic branching is a SM3 feature but you can still use if-statements in SM2 since the compiler will handle them. However, they are always fully evaluated so you won't get a performance benefit.

Alpha testing is always done in the shaders now. GL3 has deprecated fixed function alpha test and D3D10 has dropped it as well. So it is not a real feature for Horde but just shader code.

Since I assume alpha test will be important for many people, I have quickly implemented it myself. Check out the latest code from the SF svn. It will also handle shadows properly.

BTW, it is great to hear that the transition from OGRE is going smoothly. I'm looking forward to your screenshots

Cool, thanks for updating the SVN, I'll go check it out.

Any ideas about the shadow map alpha test? Basically, to do foliage you need to have the diffuse map passed to the shadow map shader so it can alpha test out the shadow map. I always was annoyed at Torque because of that (there's no point having nice foliage and tree X's if youre shadow draws a whacking great lump of shadow under it

Oh, never mind, looks like you already fixed the shadow map. Ta.

Hmm, ok, so the shadow map seems not to be correctly alpha testing? Plus the shadowing and lighting on the trees doesnt quite work does it

Couple of things that might be needed: a double sided material, plus some way of telling objects not to cast/recieve shadows. Especially on themselves.

BTW: Those are NOT shots of the game. Its just a model I loaded in the engine to test out the rendering stuff. The game is considerably weirder than those shots

I quickly tried out alpha tested shadows before submitting them and they worked fine for me. You can try to modify the threshold which is currently hardcoded in the shader to see if there is any effect at all.

Two-sided materials require special handling in a shader. For example, the normal could be flipped in the vertex shader based on the sign of the dot product of normal and view vector.

For making objects not cast a shadow, we could introduce a new material option. Having objects not receive a shadow is a bit more complicated. With forward shading it can be done with a shader flag which makes the shadow term in the lighting function optional. For deferred shading it is a lot more complicated.

BTW, nice screenshots!

Ok, changing the depth for the float on the alpha rejection worked. But there's another minor snaggette

You forgot to flip the texture coordinate of the textures going into the shadow map. It just needs the .t flipping before being used.

I just modded line 269 of model shader to:

#ifdef _F05_AlphaTest
texCoords.t *= -1.0;
vec4 albedo = texture2D( albedoMap, texCoords );
if( albedo.a < 0.01 ) discard;
#endif

Which works out pretty well. Although for trees its still not 100%.

Which brings up some other issues. Especially for this cityscape type environment. I cant seem to find a way to alter the ambient light for the whole of the city mesh. What I mean is that I want the city to be mostly bright, with just the shadow map for contrast. Right now I've got a big spotlight, but its not big enough, with enough range to fill the whole city (the large city is LARGE). Which means that I get dark edges around the periphery of vision when looking out over the city. The alternative of course, is to push the light out further and increase its range, but it seems to me that would screw up the shadow map resolution. Is there a reasonable fix for this?

I'm not necassarily going to be using the scene, but I think its useful as an exercise in getting the rendering to look right.

Ta.

You are right, the tex coords need to be flipped!

The current ambient solution implemented in the samples is using an ambient cube map which is sampled based on the geometry normal. You can modify that texture to change the ambient lighting.

Pushing the spot light out quite far should be ok. We are using cascaded shadow maps, so the shadow resolution is always optimized for the near part of the viewing frustum. The light has a parameter which determines the shadow map distribution and that can be tweaked to influence the shadow quality tradeoff between near and far geometry.

Alternatively, the shaders could be modified to do directional lighting instead of spot light computations. If you know the shader system a bit, this will be very easy to do.

BTW, is the city your model or is it publically available? It could be a nice test case for shadows, occlusion culling and huger scenes in general.

Its one I bought from www.3drt.com a few years ago. Its definitely good value, but ended up not being right for the project I was working on.

It definitely is a good test case though.

My actual project is pretty far away from it though. Its a grid based city scene (like a city building game, but not). But its fun to try out some of these things on the old mesh.