Vertex Buffer Terrain

So I have been bashing my head against many walls lately, but overall have found JME to be very accessible and simple to use. I spent a fair bit of time looking through the built in terrain system and several aspects have led me to believe rolling my own terrain would be a better option to allow me to really fine control how its done, and avoid any extra overhead from the many features and capabilities of the built in system.

So creating rendering terrain was no issue, creating custom geometry quads with LODs etc. But I would really like to streamline the terrain to allow for much larger viewing distances and faster performance. This brought up 2 concepts which I used before back in my XNA days but am not sure how well they translate here and I am super duper rusty.

Issue 1: IndexBuffers

I am unsure if this would even be considered a good technique in this day and age, but one of my original terrain implementations used an index buffer that contained all variations of LOD as one long buffer, and I could then define an offset and length for what would actually be passed to the GPU. This removed any need to swap my index buffer for every LOD change. My testing hasn’t shown a noticable impact just swapping the buffer, but im also not at a point yet where I have enough going on to even remotely bog down my system.

So I guess my question is, is this even possible to achieve in JME and is it worth it.

Issue 2: Vertex Shader Geometry
Another fun trick I have read about and used, is to send a very small amount of data to the GPU which helps quite a bit when dealing with large terrains. Basically I know the spacing of my vertexes in the quad grid, and it is constant so the vertices never move on the xz plane. The only dynamic position would be the z axis, so the goal would be to use the Type.Position buffer to just send a float[] array of single floats per vertex, then in the shader extrapolate the xz position of the vertex based on the texture coordinates since I also know the width & height of the quad.

This would in theory greatly reduce the amount of memory and data needed to generate the terrain since I no longer need to send a vector3f.

One initial concern with this method is dealing with bounding and collision since the engine effectively has no idea what the terrain is or looks like as it would be generated in the vertex buffer.

Second issue Is I have attempted to implement this as a basic test with 0 success. I just have a black screen and only register the verts/tris when I look at 0,0,0.

I am passing the array of float values for height (simple 0f for testing to create a flat grid) like this.
[java]mesh.setBuffer(Type.Position, 1, BufferUtils.createFloatBuffer(vertices));[/java]

My vert shader is identicial to the Unshaded.vert shader with the following addition.
[java]#ifdef HAS_VERTEXCOLOR
vertColor = inColor;
vec3 newPosition;
newPosition.x = inTexCoord.x * 65 * 3;
newPosition.z = inTexCoord.y * 65 * 3;
newPosition.y = inPosition;

vec4 modelSpacePos = vec4(newPosition, 1.0);
#ifdef NUM_BONES
gl_Position = g_WorldViewProjectionMatrix * modelSpacePos;[/java] 

If anyone has any suggestions on what i’m screwing up, how terrible I am at this, or if I am simple on the completely wrong path it would be very helpful. Thank you for taking the time to read.

if you change the .j3md file to use GLSL 110, it should crash (hopefully), and you’ll get an error here:

[java]inTexCoord.x * 65 * 3;[/java]

multiplying a float and integer. Try 65.0 and 3.0

Switched GLSL110 and changed the ints to floats, no crashes app still runs but seems to exhibit the same behaviour. Set the background to a funky color to make sure it wasn’t just rendering black tris on black, but no nothing is visible, tried switching culling settings for mat and geometry, made no difference. Still just seems to exist at a point in space.

Which is not surprising since I’m probably totally f’ing something up in the shader.

I should add for the purpose of debugging I am seeing all the verts and tris in the debugging hud, even LOD switching for the tris seems to be functioning,