Transparency and the grass?

#1 I had this same problem. I don't think there is a way to fix it (though I am an artist, not a coder), but you can reduce the effect by tweaking with the alpha cut-off.

#2 What sort of transparency are you referring to? The problem has to do with depth masking. Before you draw the grass, you'll need to turn off the depth mask, like this:

glDepthMask(GL_FALSE);

then draw the grass, then turn it back on:

glDepthMask(GL_TRUE);

If you don't, then the transparent pixels in the depth buffer will be overwritten, blocking anything behind them from view.

#3 Just to clarify what he's talking about, here's a pic:


Notice how you can see the sky and then (lower) the terrain on the part of the grass that is supposed to be transparent? I just noticed this prob last night and will look into it in a couple days... if I find the solution I will post it.

#4 As I said, you can greatly reduce this effect by adjusting the alpha cut-off. To the point that I don't think you need to worry about changing the code. "Choose your battles..."

#5 This all originates from my code.

There are many roads to doing grass and many considerations to take into account when rendering. My original code has been used as a template to create some great stuff but like any imaging problem, each needs to be tuned to each situation.

My original intent was to create an object that could literally blast billboards onto the screen as fast as possible. This is what it was tuned to do but to do this I needed to take a few shortcuts.

The first being the ability to maintain a database of hundreds of thousands of billboards but be able to control which of these are processed so I put a quad-tree culling system in-place to handle this. I also wanted to sacrifice memory for rendering speed and this is what I did. In my SOTD I had a level with a million billboards being rendering at high framerates, only 60,000 were actually being rendered in the view.

The second was the problem of sorting. If I were to disable the use of the depth buffer, I would need to sort the billboards which would be costly, particularly when you're talking about the numbers I intended to handle. To this end I decided, for speed, I would leave depth testing on and not sort.

The problem with this approach, although fast, is that the billboards have semi-transparent or totally transparent areas. A transparent pixel that writes into the depth buffer is a hazard and produces an invisible barrier to rendering. To solve this I enabled alpha testing which allows you to control to what level of alpha will actually be rendered. This happens before the depth buffer writes and so solves the problem, at least partially.

The problem created here is choosing the alpha level, which I provide a field for in the fxFoliageReplicator. Too much and you clip the alpha edges of the billboard, too little and you end up with the effect as shown above.

If interpolation is turned off you completely remove this effect (GL_NEAREST) but creates pixelated billboards, especially close-up. Because of interpolation though, particularly when billboards cluster, this level needs tuning, too much rather than too little.

Anyone wanting to change the way this object works (or any hybrids) can do so easily. We are only talking about enabling a setting or disabling another. If you are not handling thousands on screen at the same time then bypass all these problems and do a Qsort or something.

Just thought I'd bring some detail to the discussion. :)

- Melv.

#6 If i remember right, in planetside, they do an initial sort from the players viewpoint once each "cel" of grass comes into view. This could be extended into each quadtree node at a specific level being sorted as it becomes visible.

Phil.

#7 Phil,

Yes, there is plenty of scope for taking the work further. This was simply the first step and a second was not taken.

I remember thinking about using the farthest corner of each viewable node as a far-plane reference and sorting to the camera for each node only once. If the farthest corner changed for that node then I could do a re-sort for it but I never did the work. That kind of change is fairly trivial and should only take an evening or two to get right.

It would certainly get the problem fixed or at least produce another unique solution that would need tuning in other ways. ;)

It ain't gonna' happen by my hands anytime soon unfortunately. :(

It would be nice to see the work finished off though, maybe I'll have a quiet weekend sometime.

- Melv.