Grass simulation for mobile

I've been making a grass simulation trying to optimize it so it runs on smartphones and tablets without destroying them, while aiming to make it look as nice as I can. So far, while not being eye-popping, I'm quite happy with the results, I think it doesn't look too bad and the performance is OK (in my Nexus 4, 47-60 FPS in portrait and 34-60 in landscape, depending on the camera position and direction), but since when you look at something for a long time you become too accustomed and lose perspective, it would be nice to hear external opinions.

Some things yet to do:

• I'd like to give the illusion that the grass never ends, even while the camera moves in any direction (not only just rotating); right now the skydome is too small to give any sensation of realism.
• Change a bit the way the wind affects the blades trying to make it "seem" a bit more realistic.
• Try to fake self-shadowing on the blades.
• Maybe add the possibility of making the grass bend when objects are on it, or when it's touched.
  
• Adjust the colors and take into account the light colors (the shader takes into account the light direction, but not the colors right now).
• Fix a bug in the specular highlights, since they look as if the light source was a bit to the right.
• More performance improvements if my brain can come up with any.
• And whatnot...

In this web build clicking and moving the mouse rotates the camera. The skydome is courtesy of the nice "Time of Day" asset, which I'll have to adjust and integrate a bit better. It is possible to change the wind direction and strength of the simulation, though not in this web build.

http://www.skiesopened.com/Grass/Grass_web_player.html

In my Windows PC everything is right, but I tried yesterday with an old MacBook and there was a problem with some "holes" in the grass, I'll have to take a look; if you see something like that, would you be so kind as to tell me the OS and browser, please?

 

Wow, I think its already fantastic!
Any way to control length/width and color of the grass blades?

 

yes it looks very good allready, you should release it for pc or mac too and not only for mobile, looks way better than the billboard unity system
edit
maybe add the possibility to add a gradient texture to the grass, something like this?

 

Wow, this looks very good already!
Can you please tell us a bit about your workflow?

 

Looks excellent, nice work.

I'd also be very interested in learning how this is done!

Any ETA on a release?

 

Beautifull, can you make a apk ?

 

I'm glad that some of you like it

As it is right now, not in real time, but when creating the meshes, as I wanted to save as many instructions and data in the shader as possible. There's not only one color for the blades, each polygon in a patch is slightly different. I also use the height of the vertices (which is random but not higher than 1) for some operations, though that value could be moved somewhere else.

Since this won't be exactly a full game, but more a visual "toy", I don't see much point in releasing it for computers; my initial idea was to make an Android live wallpaper, and maybe a standalone app to play a bit with it.

I hope to finish this scene this month, but who knows...

Not sure if with those last two comments you were referring to an asset for the grass simulation... If that's the case, I've been thinking about making an asset for the asset store, and certainly some extra money would be really helpful for me at this moment, but I don't know if that will be possible... The thing is that I am optimizing everything for this particular scene, so the system is not so flexible for many use cases, and, while some parts are automated, others still have to be done manually. I could fix all that, but that would take time and effort, and I don't know if that would be worth it.

Actually, I'm already using a gradient; the effect it's very subtle, but it can be noticed when removing it.

I'm not a graphics expert in any way, so there's no magic here and quite probably some things could be done in a better way. Also, I'm not an expert with explanations (much less in English)

Basically, each blade is a single triangle. The problem with this is that you can't just use regular normals to calculate the illumination (at first I used 3 conected triangles and 4 normals, so that the blades didn't seem to "disappear" when rotating the camera, but that wasn't a good idea, when I switched to 1 triangle I could achieve a much better sensation of density with better performance). I thought about the usual procedure of duplicating the vertices and triangles with the normals inverted, but I wanted to find another option without adding geometry, and at the end I just got rid of normals and the usual illumination algorithms and just use the screen-space positions of vertices and the light direction for the computations (and, yes, at some point I tried "faceforward" but didn't like the results, with some angles it doesn't produce correct results, I guess due to precision problems, and can be quite noticeable when the camera rotates).

Also, to save vertices I don't just place some triangles randomly on the ground, but the lower vertices are arranged in a grid, so each one is shared by 4 triangles. Using a triangular grid would allow me to share each vertex with 6 triangles and further lower their number, but I'll have to take a look at it and see if there's any problem with that aproach. Of course all the vertices positions are randomized by a small amount, otherwise everything would look completely uniform. And the geometry is grouped in individual rectangular patches and several of them are placed in the scene.

For the wind movement I use a moving noise texture to calculate a skew matrix. At first I wanted to compute it in the vertex shader, but the thing is that not all OpenGL ES 2 devices support texture lookups in vertex shaders, so I'm using the CPU for that: for each visible patch I sample the texture (actually a pair of arrays pre-filled using two channels of the texture) at some positions, make some calculations and send the resulting data to the vertex shader. Each sampled position corresponds to many vertices (otherwise there would be way too much data for the CPU to calculate, and also there are limits in the amount of uniforms you can use in the shaders); to reduce a bit the impression that the vertices are moving in groups, while retaining the effect of the wind moving the blades in a particular direction instead of randomly, consecutive vertices are assigned different, but close, sampled positions. It's not perfect, but way better than just using the closest position for each vertex; I'm thinking about additional ways of improving it (and just had an idea right now). For now I'm using C#, but when the code is completely finished I'll port it to C to improve the performance. Oh, and I also accentuate the effect of the wind by slightly changing the vertex colors.

I think the biggest performance eater here is the crazy amount of overdraw which is happening, with so many triangles being drawn. Actually, even when there's no overdraw I'm getting lower framerates, but I would say the problem may be the high amount of z-tests that the GPU must perform, since when looking at the grass from the top (which would lower the number of pixels that each triangle is using), even while seeing the entire scene, the FPS increased, and also when lowering the resolution. So what I'm doing is rendering the further patches using lower resolutions (with a render texture), so that fewer pixels are computed; for example, in the current scene I'm using three different resoultion levels. That also has two other advantages: since it's not very noticeable, I can use meshes with fewer geometry for patches rendered using lower resolutions; and the distant patches are slightly blurred, a not-so-nice but cheap DOF-like effect.

If I give more details it would be quite long, and I find it difficult to explain all (and there are some things I just can't explain, I just experimented and they worked!), so let's say magic and fairy dust for now

 

Sure, here it is. If you could report the performance in your device or any problems, it would be really appreciated. Take into account that, at the moment, changing the device orientation while executing the app will mess a bit the graphics (since the render textures don't change their resolution), so to try with a different orientation the application must be restarted.

 

Hello,
It's very slow on my 2 Android devices.

 

Looks great, but idk what this black gap is?

 

Possible too many triangles? check the number.

 

The amount of triangles is insane, indeed, but the problem is that I wasn't setting the correct resolutions for the render textures in some instances. I think it should be fixed now, could you try again?

Thanks for checking, can you tell me which Android devices have you used, and the FPS, please? There're still performance improvements to be made, though the scene is really intensive and will be slow on less powerful devices (or those with a very high screen resolution, I can just lower it in these instances).

 

It's a French brand(low cost)
I didn't see FPS on your screen.

Android 4.4
2x1.3Ghz CPU
540x960 px
18FPS

Android 4.2
Texas Instrument OMAP 4460 CORTEX A9 , 2x1Ghz CPU
1280 x 800 pixels
7FPS

 

Thanks. If they are low cost devices, it's expected that the application runs slowly. I'm trying to optimize it as much as I can, but the scene really needs at least a mid-range device. I guess that lowering the resolution would help here, though I don't know to what extent.

I've spent the last two days trying to figure out how to setup an oblique frustum without modifying the final projected image, but using a custom far clipping plane instead of a near one. Since in most situations only the top of the distant blades will be visible, but the whole blade will still be drawn or z-tested, which is what eats a lot of computing time, my idea was to just clip them leaving only the top really visible by modifying the far clipping plane so it's always parallel to the ground and at some (variable) distance from it to "cut" the blades. I've finally managed to generate such a frustum, but at the end it has only slowed the application down... I guess the gains achieved discarding fragments are negated by the extra computations needed to clip the geometry, though I really didn't expect it.

At the end I'm now just lifting the lower vertices of distant blades in the vertex shader. The problem is that I cannot approximate the original shape of the blades by moving the bottom vertices towards the top vertices, since each bottom vertex is shared by several triangles (and, thus, several top vertices), though it's not too noticeable (and I think it can be improved a bit), and I'm getting a palpable performance improvement.

 

I would like to have that grass without the performance improvement also, is it possible to have the original perfect looking version in the pack as well ?

This is usefull for my game that needs a very fast grass approach, and i hope it is not only for mobile. A performant grass is not just good for mobile, but also for PC games that are resource hungry and would require a faster approach.

Since i wont be using it on mobile, maybe a separate PC version would be a good idea as well.

 

Looking forward to it. Hope it has less draw calls and polygons.

Tested on samsung s5, runs smooth, but not sure how it will be when player moves.

 

Though I thought about it, this project wasn't really intended to be an Unity asset, but nothing more than an Android app, and thus I'm making it to fit this particular scene and setup. If people are interested I could adapt the grass to be more flexible and work on different cases, but that would take more time and effort than I can dedicate right now, I'm afraid.

 

I would suggest a release of a first version of the current system and update it later, increasing the price accordingly.

 

That's an option, first I'll finish my app and then I'll think about it.

 

Hi, this grass has been released? I am trying to make something like this to put on my mobile game, but no ideia how keep low the draw calls.

 

It's not released, it wasn't really intended to be released as an asset/plugin, it would require a lot of work to make it usable on different cases without the end user having to make several adjustments to the code. I may release something at some point, but if it happens it wouldn't be anytime soon, I'm afraid.