Three.js Get local position of vertex in shader, is that even what I need?

Question

I am attempting to implement this technique of rendering grass into my three.js app.

http://davideprati.com/demo/grass/

On level terrain at y position 0, everything looks absolutely fantastic!

Problem is, my app (game) has the terrain modified by a heightmap so very few (if any) positions on that terrain are at y position 0.

It seems this vertex shader animation code assumes the grass object is sitting at y position 0 for the following vertex shader code to work as intended:

    if (pos.y > 1.0) {
        float noised = noise(pos.xy);
        pos.y += sin(globalTime * magnitude * noised);
        pos.z += sin(globalTime * magnitude * noised);
        if (pos.y > 1.7){
            pos.x += sin(globalTime * noised);
        }
    }

This condition works on the assumption that terrain is flat and at position 0, so that only vertices above the ground animate. Well.. umm.. since all vertices are above 1 with a heightmap (mostly), some strange effects occur, such as grass sliding all over the place lol.

Is there a way to do this where I can specify a y position threshold based more on the sprite than its world position? Or is there a better way all together to deal with this "slidy" problem?

I am an extreme noobie when it comes to shader code =]

Any help would be greatly appreciated.

I have no idea what I'm doing.

Edit* Ok, I think the issue is that I am altering the y position of each mesh merged into the main grass container geometry based on the y position of the terrain it sits on. I guess the shader is looking at the local position, but since the geometry itself vertically displaced, the shader doesn’t know how to compensate. Hmm…

Ok, I made a fiddle that demonstrates the issue: https://jsfiddle.net/titansoftime/a3xr8yp7/

Change the value on line# 128 to a 1 instead of 2 and everything looks fine. Not sure how to go about fixing this.

Also, I have no idea why the colors are doing that, they look fine in my app.

Answer 1

If I understood the question correctly:

You are right in asking for "local" position. Lets say the single strand of grass is a narrow strip, with some height segments.

If you want this to be modular, easy to scale and such, this would most likely extend in some direction in the 0-1 range. Lets say it has four segments along that direction, which would yield vertices with with coordinates [0.0, 0.333, 0.666, 1.0]. It makes slightly more sense than an arbitrary range, because it's easy to reason that 0 is ground, 1 is the tip of the blade.

This is the "local" or model space. When you multiply this with the modelMatrix you transform it to world space (call it localToWorld).

In the shader it could look something like this

void main(){
   vec4 localPosition = vec4( position, 1.);
   vec4 worldPosition = modelMatrix * localPosition;
   vec4 viewPosition = viewMatrix * worldPosition;
   vec4 projectedPosition = projectionMatrix * viewPosition; //either orthographic or perspective

   gl_Position = projectedPosition;
}

This is the classic "you have a scene graph node" which you transform. Depending on what you set for your mesh position, rotation and scale vec4 worldPosition will be different, but the local position is always the same. You can't tell from that value alone if something is the bottom or top, any value is viable since your terrain can be anything.

With this approach, you can write a shader and logic saying that if a vertex is at height of 0 (or less than some epsilon) don't animate.

So this brings us to some logic, that works in some assumed space (you have a rule for 1.0, and 1.7).

Because you are translating the geometries, and merging them, you no longer have this user friendly space that is the model space. Now these blades may very well skip local2world transformation (it may very well end up being just an identity matrix).

This messes up your logic for selecting the vertices obviously.

If you have to take the approach of distributing them as such, then you need another channel to carry the meaning of that local space, even if you only use it for that animation.

Two suitable channels already exist - UV, and vertex color. Uv's you can imagine as having another flat mesh, in another space, that maps to the mesh you are rendering. But in this particular case it seems like you can use a custom attribute aBladeHeight that can be a float for example.

void main(){
     vec4 worldPosition = vec4(position, 1.); //you "burnt/baked" this transformation in, so no need to go from local to world in the shader

     vec2 localPosition = uv; //grass in 2d, not transformed to your terrain
     //this check knows whats on the bottom of the grass
     //rather than whats on the ground (has no idea where the ground is)
     if(localPosition.y){
        //since local does not exist, the only space we work in is world
        //we apply the transformation in that space, but the filter 
        //is the check above, in uv space, where we know whats the bottom, whats the top
        worldPosition.xy += myLogic();
     } 
     gl_Position = projectionMatrix * viewMatrix * worldPosition;
}

To mimic the "local space"

void main(){
   vec4 localSpace = vec4(uv,0.,1.);
   gl_Position = projectionMatrix * modelViewMatrix * localSpace;
}

And all the blades would render overlapping each other.

EDIT

With instancing the shader would look something like this:

attribute vec4 aInstanceMatrix0; //16 floats to encode a matrix4
attribute vec4 aInstanceMatrix1;
attribute vec4 aInstanceMatrix2;
//attribute vec4 aInstanceMatrix3; //but one you know will be 0,0,0,1 so you can pack in the first 3


void main(){
  vec4 localPos = vec4(position, 1.); //the local position is intact, its the normalized 0-1 blade

  //do your thing in local space
  if(localPos.y > foo){
     localPos.xz += myLogic();
  }

  //notice the difference, instead of using the modelMatrix, you use the instance attributes in it's place
  mat4 localToWorld = mat4(
    aInstanceMatrix0,
    aInstanceMatrix1,
    aInstanceMatrix2,
    //aInstanceMatrix3
    0. , 0. , 0. , 1. //this is actually wrong i think, it should be the last column not row, but for illustrative purposes, 
  ); 

  //to pack it more effeciently the rows would look like this
  // xyz w
  // xyz w
  // xyz w  
  // 000 1
  // off the top of my head i dont know what the correct code is
  mat4 foo = mat4( 
    aInstanceMatrix0.xyz, 0.,
    aInstanceMatrix1.xyz, 0.,
    aInstanceMatrix2.xyz, 0.,
    aInstanceMatrix0.w, aInstanceMatrix1.w, aInstanceMatrix2.w, 1.
)

  //you can still use the modelMatrix with this if you want to move the ENTIRE hill with all the grass with .position.set()
  vec4 worldPos = localToWorld * localPos; 
  gl_Position = projectionMatrix * viewMatrix * worldPos;
}