Texture shadow texcoord output for GrassLayer VP (and patch)

I've been trying to get dynamic lighting working properly with PagedGeometry's grass. To this end, I've modified the VP created in GrassLoader.cpp to support spitting out texcoords for integrated texture shadows (using a depth shadow mapping setup stolen shamelessly off the wiki here.)

OBScreenshot:
Full size: http://lovecraft.arpatubes.net/~sid/screenshot_30.jpg

Note: this diff also contains the lighting patch contributed by Captnoord/Arc, because that's kind of a prerequisite (shadowing makes 0 sense without diffuse lighting) and isn't in svn yet afaik.

Unified diff: http://lovecraft.arpatubes.net/~sid/PG_Shadowing_Lighting.diff

Note: for shadowing to actually work, you need a fragment program which occludes the diffuse contribution for a fragment in shadow: a trivial CG one is here, including a sample material: http://lovecraft.arpatubes.net/~sid/PG_Shadow_Example.tar.gz. You will be able to do better, this code was more or less lifted wholesale from the Ogre Wiki.

Further note: I'm developing on Linux/GL. From time to time I cross-build my code and try it in wine or on my fiancee's windows box. I have not done that here, and truth told I'm not even certain whether the fragment program in the example will work under ps_1_1. In any event, somebody should figure out if this works in DirectX. I honestly have no idea.

Very nice! Those screenshots look really good.

I'm sure this code will be very helpful for integrating dynamic shadows more properly into the grass system.

Very nice! Those screenshots look really good.

I'm sure this code will be very helpful for integrating dynamic shadows more properly into the grass system.

Thanks JohnJ

Also, I've been looking at trying to give the grass quads realistic (i.e. surface-approximate) normals, because Arc's approach of 'set the normal to be positive y' works fine on a flat surface, but looks terrible on a hill (which is either going to be more or less lit than a flat surface is, depending on lighting.)

Unfortunately, it seems that you're using the normal to store quad orientation information. Is there any technical reason why this can't be moved to, say, texcoord2? It'd then be (I assume) somewhat trivial to figure out the correct normal for each vertex using the height function (in fact, this would likely give you the binormal for free, which will give you everything you need for a tangent basis matrix and tangent-space lighting.)

Any reasons why you don't think this would work?

Also, I've been looking at trying to give the grass quads realistic (i.e. surface-approximate) normals, because Arc's approach of 'set the normal to be positive y' works fine on a flat surface, but looks terrible on a hill (which is either going to be more or less lit than a flat surface is, depending on lighting.)
True. The only reason the grass doesn't do dynamic lighting better already is because PagedGeometry supports fixed function video cards, and the only way to really cleanly add dynamic lighting to PagedGeometry would be to go all-shaders (probably SM2.0) - in other words adding lighting properly would break the fixed function support. If I ever make PagedGeometry 2.0 it's definitely gonna be shader based.

Unfortunately, it seems that you're using the normal to store quad orientation information. Is there any technical reason why this can't be moved to, say, texcoord2?
There's no reason in particular why the quad info uses the normals, so you should have no problems changing that to something else.

It'd then be (I assume) somewhat trivial to figure out the correct normal for each vertex using the height function (in fact, this would likely give you the binormal for free, which will give you everything you need for a tangent basis matrix and tangent-space lighting.)

Any reasons why you don't think this would work?
Sounds like it'll work to me

True. The only reason the grass doesn't do dynamic lighting better already is because PagedGeometry supports fixed function video cards, and the only way to really cleanly add dynamic lighting to PagedGeometry would be to go all-shaders (probably SM2.0) - in other words adding lighting properly would break the fixed function support. If I ever make PagedGeometry 2.0 it's definitely gonna be shader based.


You've already lost your ability to realign quads in the VP if you assume fixed-function, amongst other things; under a fixed function setup, you're not going to be running the VP, which means certain things won't work...

Realistically, though, in order to get any form of dynamic lighting on something like grass, you're going to need a vertex program. Since there's already a vertex program being built, adding lighting to it doesn't seem to me to cause problems on fixed function cards, it just means that proper lighting is a feature that won't work on fixed function (although PG's grass itself will still work, just not lit properly.)

In any event, this seems trivial enough to me that I'll probably post a patch here in a few hours when I get home from work.

As a side effect, I'd suggest that since I'll just be computing normals based on the terrain and placing them in the normal attribute slot in the vertex buffer, the grass itself should light properly under fixed function (albeit without tangent-space lighting computations or anything fancy.) Are there likely to be any issues with telling the fixed function pipeline to turn lighting ON for the grass?

You've already lost your ability to realign quads in the VP if you assume fixed-function, amongst other things; under a fixed function setup, you're not going to be running the VP, which means certain things won't work...
I know, that's why when it detects that shaders aren't available, it automatically switches to a fixed-function implementation. In this case it swaps StaticBillboardSet for Ogre's BillboardSet class, which uses dynamic vertex buffers to realign the quads, etc. on the CPU.

Realistically, though, in order to get any form of dynamic lighting on something like grass, you're going to need a vertex program. Since there's already a vertex program being built, adding lighting to it doesn't seem to me to cause problems on fixed function cards, it just means that proper lighting is a feature that won't work on fixed function (although PG's grass itself will still work, just not lit properly.)
True, it's just that PagedGeometry is essentially using a dual implementation for shaders/no-shaders, and the purpose of a dual implementation is for compatibility, not broken features between the two.

In other words, adding a lot of shader-based features without duplicating them in the fixed function version means having fixed function at all will become useless as a fall-back.

Personally I'd love to remove all fixed function support from PagedGeometry completely, but unfortunately I can't do that without breaking it for people who rely on it. This is why, like I said, a PagedGeometry 2.0 will definitely be purely shader based.

In any event, this seems trivial enough to me that I'll probably post a patch here in a few hours when I get home from work.

As a side effect, I'd suggest that since I'll just be computing normals based on the terrain and placing them in the normal attribute slot in the vertex buffer, the grass itself should light properly under fixed function (albeit without tangent-space lighting computations or anything fancy.) Are there likely to be any issues with telling the fixed function pipeline to turn lighting ON for the grass?
Currently PagedGeometry's lighting system is totally non-dynamic, but it works - grass and trees can have colormaps (basically level-based light maps) applied that darkens them wherever you want. This is the current "official" way to do lighting on grass/trees/etc.

Your modifications are really good (obviously), but unfortunately I don't think there's any way to really practically implement them in the fixed function version - or at least it's not worth the effort. Fixed function is basically (for all practical purposes) limited to static lighting, and unfortunately this means PagedGeometry's (official) shader code is limited to the same until I can transition into a version that is strictly shader based.

Not to hijack this thread but maybe we should make a use case poll asking for people relying on fixed function? Not sure how much are out there anyway these days...

Not to hijack this thread but maybe we should make a use case poll asking for people relying on fixed function? Not sure how much are out there anyway these days...
That's a good idea, but like you say it's easy to anticipate the results - almost nobody relies on fixed function these days.

I'm willing to remove all the fixed function support from PagedGeometry and start implementing a dynamic lighting system, but I don't really want it to be a transition (like some systems being dynamically lit, and others not). If it's not all static lighting (like it is now), it should be all dynamic (which is what I planned for a PagedGeometry 2.0).

Contributions like these are very helpful for sure towards that goal, I'm just a little uncertain about adding them into the official version without a full change to dynamic lighting, and even then, some people will still want the old version.

Unfortunately I currently don't have the time to do a major rewrite of PagedGeometry, but I will be making a vegetation system for my planet/galaxy engine which will include all these features and may be adaptable for flat terrains, which is why I'm hesitant to do it all twice.