So the current issue we have ( now that we have working sexy alpha based grass ) is that we dont want a simple grass block with a silly X on it.

Instead we want something with a bit of a dynamic feel to it.

We had a previous grass thread with many great suggestions ( click here to read it ), but the issue is that our land is 100% dynamic and block/voxel based. This means that normally a single grass object can rely upon one block at a time. The problem with this is that when you do this setup you get the minecraft shot we had above.

However, we could stack a bunch of model blocks into one block:

But unless you allow for some overhang you are going to still get the problem we had with minecraft which is some nasty looking topdown or 45 degree looks. So you say "Why dont you just allow for overhang?"

If we allow for overhang, what would we do if somebody destroyed block 1? Simple answer is to destroy all of the grass blocks that take up space in block 1, but this only works if the art assets support such a theory. If we make a grass plane that is long and that spreads to the edges ( but is spawned on the edge ) we would have a grass plane that looked like it was hanging off with odd grass out in the middle of nowhere.

Note: While posting this i figured out that i could fix this by limiting the width of the base and spawning multiple instances from the origin of the model/plane and fanning it out from there. I would like to not have to be limited by that though.... so ill keep posting.

So the next question would be, how can we code something that has to be reliant upon dynamic terrain changes that will allow for a more dynamic feel? Is there a way to allow for overhanging grass that will be removed when block 1 is removed?

What is exactly your problem here, that the grass looks like an X when looked from above or how the grass is distributed on the ground?

For the former the first idea I have is to just give the grass mesh a different shape, e.g. a downwards pyramid shape (then at least it would look like a 3D mesh from any angle instead of looking like a bunch of quads). It requires more triangles, of course, although you can decide how much detail you can afford to spend.

Can't come up with suggestions for the latter, since I can't understand exactly what would be the issue with the distribution of the grass. Got completely lost at the overhang part.

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

Here we have a nice sexy block 1 and 2, on block 2 is the spawned grass that we created. ( note that it has a very long base )

Here we have the same as the previous image but the grass is spawned inbetween 1 and 2 as well as on 2. This creates for a more realistic look when at an overhead or 45.

In this picture we remove block 2 and notice that because of the long base of the grass model we have some issues. 2A grass block would be destroyed but 1A could or could not depending on how you wanted to do it. ( which is part of the problem, deciding how to do it )

While making the post I realized that if i make the base of the model smaller we could allow for edge spawning to occur without having to remove the grass model and it would still look okay!

But I do not want to be limited by this because it would limit the style that a person could use ( mods are allowed ) and would limit the style of grass being created. It is a solution though. Last but not least this is the current grass we have

1) Bend the grass quads, and use at least 3-4 of them at different angles/positions. Any modern game seems to use few more quads at different angles so it looks good from any direction. The texture of the grass and how it blends with the terrain is also important, otherwise you have nasty edges and it doesn't look good. This plus some random rotation applied to each blade should give a good result without much work.

2) I'm not sure how you generate grass but you can re-generate it once blocks are changed, so you can easily spot which block (that was base for generating grass) disappeared and just don't generate grass there. As you use uniform grid of cubes it will be harder to make a good looking grass distribution - if you used marching cubes mesh, you can easily create a method that will distribute grass over the surface of a "grass triangle", make it conform the normals of terrain, decide, decide on number of grass chunks depending on the size of triangle face etc. I did it and it looked okayish (considering how little time and effort I put into it) also from above, but can't find a picture found a picture!. Its just a single grass billboard distributed quite densely, plus randomly rotated at each position so not a single quad has the same orientation. The terrain is fully diggable so I had the problem of removing the terrain from underneath the grass, but it was easily solved by just rebuilding certain grass chunk taking into account new mesh that didn't have certain grass triangles (but rock for example).

I guess you have it a bit harder because whatever you do, all you have is cubes so distribution will always be tied to these cubes, unless maybe you create some sort of "terrain mask" on which you paint where the grass should appear and apply grass distribution based on this mask, so its not tied to cubes - some engines use such masks to "paint" grass over terrain, but its heightmap, so in case of 3d voxel volume terrain it may not be that easy to achieve.

Out of curiosity, what stops you from swapping grass models when you remove a block? You could switch to a more appropriate length on block removal

Not a bad idea, this is possible too depending on how hard it is. The problem that I see is how to poll what grass is in what area? normally a grass block takes up a block so there is a simple method by calling the block/box. If we remove that we are now polling everything for grass? could be a memory hog.

I guess you have it a bit harder because whatever you do, all you have is cubes so distribution will always be tied to these cubes, unless maybe you create some sort of "terrain mask" where you generate a mask where the grass should appear and apply grass distribution based on this mask - some engines use such masks to "paint" grass over terrain, but its heightmap, so in case of 3d voxel volume terrain it may not be that easy to achieve.

That is indeed the problem. Thanks for the posts guys. Keep the ideas coming

Not a bad idea, this is possible too depending on how hard it is. The problem that I see is how to poll what grass is in what area? normally a grass block takes up a block so there is a simple method by calling the block/box. If we remove that we are now polling everything for grass? could be a memory hog.

Isn't your grass sorted in some way already? If you don't have some kind of paging* system in place you might run into performance constraints later if you wind up having a lot of grass

Edit: when I say paging I'm thinking octree or other spatial hierarchy

So it's already sorted by chunk, that'll do just fine. What stops you from simply looping through the grass strips of the removed chunk and adjacent chunks and applying your chosen solution?

You needn't necessarily delete any offending grass strip*, either. If you want all the strips to use exactly the same model and similar geometry, simply rotating or translating an existing strip a little bit to a new valid position might even work.

Um, let me see if I understand this correctly: do you have the grass be part of the cube mesh? Because if it was a separate mesh you could just remove the grass at a whim and none of this would be an issue...

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

So we ran into another problem. The lighting system for our world is deferred rendering, but with such a system you can not have alpha's that work right. We got the alphas to work for the grass but to get the lighting to work on them we had to setup a forward lighting process. In doing so our point lights do not effect them. Any ideas on how we could fix this? If we setup point lights to be forward rendered we limit the number of lights. One of the main reasons for using a deferred rendering method is the thousands of lights we can use. ( which makes for a very nice setting ) I would really hate to have to hinder that based off of the idea of grass being lit.

So we ran into another problem. The lighting system for our world is deferred rendering, but with such a system you can not have alpha's that work right. We got the alphas to work for the grass but to get the lighting to work on them we had to setup a forward lighting process. In doing so our point lights do not effect them. Any ideas on how we could fix this? If we setup point lights to be forward rendered we limit the number of lights. One of the main reasons for using a deferred rendering method is the thousands of lights we can use. ( which makes for a very nice setting ) I would really hate to have to hinder that based off of the idea of grass being lit.

Any unique ideas on how we can bypass this would be GREAT!

Are you rendering grass fully alpha-blended? This is not how its usually done (from what I know, and I researched this subject a bit). You want to render grass with one of these methods:

just alpha-tested (easiest but worst looking solution)

alpha to coverage (not sure how it will work, or even if its possible with deferred rendering)

And now our issue is the point lights do not work on the grass because the point lights are rendered through our differed rendering system not the front rendering system used for the grass lighting. We cant run our grass rendering through the same lighting as differed because it will negate the use of alphas. So, not sure your answer really hits home as to what can be done to fix that. I do appreciate the links though as it helps to solidify our already established base. The issue is figuring out how to get point lights ( with the differed rendering ) to effect the grass.

You can kinda tell with the last bit of the video that the grass is not taking the red light on it, like it should.

Just to make sure I understand: You are rendering the grass completely "forward" and it doesn't appear in the GBuffer anywhere before that?

I can think of two things off the top of my head:

- Simply light the grass "forward". But, as you said, this would mean that you're coupling scene geometry with light complexity again.

- "Cheat" by using the values in the light buffer that are along the bottom edge of the grass quad. This is probably going to be very computationally cheap but will make the quads have constant lighting along the vertical axis. It will also make any grass automatically translucent.

Just to make sure I understand: You are rendering the grass completely "forward" and it doesn't appear in the GBuffer anywhere before that?

I can think of two things off the top of my head:

- Simply light the grass "forward". But, as you said, this would mean that you're coupling scene geometry with light complexity again.

- "Cheat" by using the values in the light buffer that are along the bottom edge of the grass quad. This is probably going to be very computationally cheap but will make the quads have constant lighting along the vertical axis. It will also make any grass automatically translucent.

Maybe I do not understand but neither of those options sound good! here is a video to show you clearly what is going on.

So as you can see the light is being rendered via differed rendering ( the point light that is ) and the grass is being forward rendered. The obvious issue is that point lights are held in the differed rendering part so that we can have lots of them present, i think its like 10,000 or something without any noticeable lag. The problem with this is that differed rendering does not allow for the use of alphas ( thus our grass method or trees or anything with an alpha ) would not render properly. My question at this point is there some "go between" method or are we stuck with this limitation. This might mean we have to go to tessellated grass via a model but I really dont want to go down that road till we have to.