Then you didn’t properly remove the billboarding code, I guess.
The billboarding expects positions to be the same for a particular triangle and then uses the texture coordinates to project them. If you’ve properly removed that code then position would just be position. Then adjust the position in world space by the wind offset. Done.
Ok, I did it!!! :P. So the trick there is to use the texCoord to know if it is a down vertex or an up one. However, this trick come with some limitations, it has to have a texture made with that in mind (my grass had a texture where the “down” is on the center and the “up” for each crossing polygon are down and up in the texture, like halving it and mirroring in the y-axis but with some differences. It doesn’t look bad in this case though). If using texture-atlas it can mess up.
Well, I think I’ve learned some great things today xD (shaders are not that ugly). I think I’ll mix all the things discussed here 
.
Thanks for your help to both of you.
I think that there is a bug with that grass shader. Over time the movement speed become faster and afaster. It ends trembling like if it were afraid of something xD.
Yeah, it’s the wind formula. Any time you are multiplying something by g_Time you will have this issue.
My own code fixed this somehow but I think I never added it back to the shaders in my demos.
Why is that?, All I can think of doesn’t make any sense looking at simarboreal’s shaders. They also multiply by g_time and they doesn’t have that issue (or, at least I didn’t see it in the amount of time I’ve been testing it).
Pretty sure you will see it there, too… or maybe that’s where I fixed it since tree wind is way more complicated.
I don’t remember the exact math but there is a layering that goes on between two periods. You want one curve’s period to be the slowing and increasing of the other period’s speed. The second period is what is doing the oscillation. As g_Time gets larger, these oscillations go crazy.
Looking at the code…
So here, we calculate a noise for some slower moving g_Time:
vec4 noise = texture2D(m_Noise, vec2(groundPos.x * 0.01 + g_Time * 0.01, groundPos.y * 0.01));
That’s fine. g_Time will move and wrap nicely until we start to lose float precision. (Which could be quicker than you might think.)
The problem is here:
wPos.x += sin(g_Time * (1.0 + noise.x)) * normalProjectionLength * strength;
We’ve based the period of our sin on a g_Time multiplier that’s using a variable multiplier.
The transitions between sin(0) and sin(2) based on noise.x will get faster and faster as g_Time increases.
The math in TreeWind.glslib is a lot more complicated as it fakes skeleton style bending based on position…
But I think the key difference is here:
float timeShift = (noise.x - 0.5) * 2.0 + gPos.x + gPos.z;
float deflect = sin(timeMultiplier * (g_Time + timeShift)) * windStrength * strength;
We keep the time shifting in the domain of g_Time and multiply by time scaling. The fluctuations in time should be more consistent this way I guess. We oscillate over a moving point in time instead of oscillating a time multiplier.