Yes, but black on the heightmap represents the lowest point on the map mesh, not necessarily a height of 0.

no I meant the terrain objects pivot point. but yeah, if your terrain height doesn't assume 0 as 0 but Olijs shaders do then that might be a cause of your issue, just modify the shaders to include some uniforms for offset values then.

I'm pretty sure the pivot point is at the center, I can make it be in blender if it isn't. I also think I should add a variable for height offset, that will be quick and easy.

Do you know what the 3D import preset is? I don't really have any clue.

In the importer? I think it's the preset that will try to detect things such as if the texture is a normal map and such.

So it's just for 3D texture as opposed to 2D sprites. Thanks, I just heard about some "3D texture" that was just a bunch of texture stuck together to be 3D.

I added a parameter called "base height", all it does is offset the whole thing. I also moved the pivot point to the middle in blender. It still doesn't seem right, and I get these weird holes: The grass in the hole isn't above or below, it looks like it's just gone.

It might be easier to analyze if you shared your scene and assets, since the original shader obviously was working for Olij as intended.

I think the problem is adjusting the scale. With my testing terrain shader, it's aligned only when the size of the plane is 100x100. I have to adjust the heightmap size parameter on both the terrain and the grass, but I don't know what to set it to. Also, note that I'm using a mesh I made in blender, the heightmap shader is just for debugging. I can send you the project, how should I do that?

5 days later

I sort of made my own heightmap generator before using this same shader.

I added a height offset, before realising that it was to do with the origin and scale of the mesh, I never went back to finish it so now looking and its still as rough as this:

float get_height(vec2 pos)
{
	//pos -= 0.5 * heightmap_size;
	//pos /= heightmap_size;
	pos /= 800.0;
	
	return (amplitude * texture(heightmap, pos).r) - 50.0;
}

My origin is in the corner and the mesh extends out positively, basically you're translating the mesh pos coords to the same in the heightmap texture.

Hope that helps

Hmm, that might actually work. I'm pretty sure the origin of the terrain mesh is in the center, but I think it has something to do with the scale. I'll change the origin to the corner and try it.

What is 800?

a month later

Maybe I'll switch to MultiMesh, that's easier to use & has some advantages. I did a test using the populate surface option, it doesn't seem to be any slower either.

The only disadvantage is I can't really fade density with distance very well with MultiMesh.

I changed my shader to fade alpha with distance, so that the grass forms a circle around the camera and not a square. Are completely transparent objects(ALPHA = 0.0) drawn, or do they get culled? If completely transparent objects get culled, this could be a good way to fade density with distance also.

They should still be drawn. You could instead use the shader to, instead of controlling alpha, move the grass outside the radius a large distance under the ground mesh so it's not visible, then it gets culled.

Now that I think about it, individual instances of a MultiMesh don't get culled anyway. Even if fully transparent objects did get culled, they wouldn't be culled in a MultiMesh.

If I'm moving meshes with a shader, it might make more sense to move it nearer to the camera, so that grass is denser closer to the camera. But now that I'm using a spatial shader instead of a particles shader, is this a good idea? If so, what would be the most performance friendly way to do it? I could check the distance from the camera, then move that mesh based on the distance, but I don't know if that's a good method, or what the best way to implement that is.

Actually, I don't think I can move grass in a shader, because I need to procedurally place the grass in a script.

In terms of order of process the shader would take effect after the script though. Vertex shader should be able to move vertices around just fine, so long as you have some input data to use for that, either vertex colors or a texture map.

Well, the problem is, I'm using a mesh and not a heightmap. After I can figure out how to do it, I want to write a script to fill the terrain with grass, like the MultiMesh "populate surface" option, except grass is placed relative to the camera. If you know of a better way, though, I'm open to suggestions.