SpiderPig

I've also noticed that the problem with my normal's are not entirely the way I'm calculating them. It seems that the lower mesh resolution toward the edges of the terrain are always going to look less detailed in lighting because they are less detailed in the mesh. i know the the terrain shipped with Leadwerks doesn't have lower resolution normal's in the lower detailed patches though, is there a technique for terrain normal's on different LOD patches that may help? #edited

Thanks for the reply Ma-Shell. I'm finding the code a little hard to translate for use in Leadwerks though. I'm assuming these are meant to Vec3? The x and y are to be the coordinates and the z the height value? Left: l [x-1; y; f(x-1, y)] Right: r [x+1; y; f(x+1, y)] Up: u [x; y-1; f(x, y-1)] Down: d [x; y+1; f(x, y+1)] Is this meant to be like this; Vec3 Left = Vec3(1,0,height_value); Vec3 Right = Vec3(0,1,height_value); Vec3 Up = Vec3(0,1,height_value); Vec3 Down = Vec3(0,1,height_value); Thanks for you help.

Unfortunately that didn't work. Using the old code: Using the new code: Vec3 tangent = Vec3(2.0, center_l - center_r, 2.0).Normalize(); Vec3 bitangent = Vec3(2.0, center_u - center_d, 2.0).Normalize(); normal_buffer = bitangent.Cross(tangent); Here is a picture in wire-frame so you can see the different levels of details: The normal's for the different levels are calculated using the same loop but with a different step value as it goes through the map.

I want to calculate the normal's from a height-map image by checking the neighboring pixels but I'm unsure on the correct way of doing it. This is the code I'm using below so far; unsigned int map_index = 0; for (int y = 0; y < map_size; y++) { for (int x = 0; x < map_size; x++) { unsigned int current_index = (y * map_size) + x; if (x == 0) { center_l = map[current_index]; } else { map_index = (y * map_size) + (x - 1); center_l = map[map_index]; } if(x == (map_size - 1)){ center_r = map[current_index]; } else { map_index = (y * map_size) + (x + 1); center_r = map[map_index]; } if (y == 0) { center_u = map[current_index]; } else { map_index = ((y - 1) * map_size) + x; center_u = map[map_index]; } if (y == (map_size - 1)) { center_d =map[current_index]; } else { map_index = ((y + 1) * map_size) + x; center_d = map[map_index]; } normal_buffer.x = center_l - center_r; normal_buffer.y = 2.0; normal_buffer.z = center_u - center_d; normal_buffer = normal_buffer.Normalize(); n_x[id] = normal_buffer.x; n_y[id] = normal_buffer.y; n_z[id] = normal_buffer.z; id++; } } "map" is just a collecting of floats representing the height for each vertex. I think there's another way of calculating the normal's for each vertex using the cross product of two vectors? But I'm not sure how to do this. Any help is appreciated.

Ah ha! Thanks very much. Knew it was something simple. Thanks for the tips too.

Sorry, I didn't explain it too well. The normal's seem to point towards the center of the world I think it is... in the editor if you move the object around or the camera, the normal's will change direction. I've attached the model also if you wanted to see it. terrain.zip

I've put together a quick shader that will show the object in wire-frame and draw lines to show the direction of each vertex normal. But the normal's don't seem to be acting correctly. Is somehow able to show me what I'm doing wrong? I have a feeling it something to do with the cameraprojection matrix, but unsure how to fix it. I used the info from this site; http://www.geeks3d.com/20130905/exploring-glsl-normal-visualizer-with-geometry-shaders-shader-library/ diffuse_shownormals.zip

VR also shows "Failed to load page data."

After the update, this line no longer works. if (window->KeyHit(Key::F2) == true) { camera->drawmode == 4 ? camera->SetDrawMode(2) : camera->SetDrawMode(4); } Also i get memory leaks detected; Detected memory leaks! Dumping objects -> {20426} normal block at 0x0E057768, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {20348} normal block at 0x0DB195F0, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {18446} normal block at 0x0DCC4540, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {16545} normal block at 0x0D731418, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {14693} normal block at 0x0BDA2748, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {13188} normal block at 0x0BAC24E0, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {12812} normal block at 0x0BA7E1F8, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {124} normal block at 0x064E3160, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {122} normal block at 0x064DF130, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {121} normal block at 0x064DB100, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {120} normal block at 0x064D70D0, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {114} normal block at 0x064D30A0, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {113} normal block at 0x0641CB98, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {112} normal block at 0x064CF070, 16384 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {111} normal block at 0x064C6FC0, 32896 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {110} normal block at 0x064B6F10, 65664 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {109} normal block at 0x064AEE60, 32896 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {108} normal block at 0x064A6DB0, 32896 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {107} normal block at 0x0649ED00, 32896 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {106} normal block at 0x06486C90, 98368 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {100} normal block at 0x03F3D9A8, 8 bytes long. Data: < w > C4 E6 F3 03 77 84 00 10 {94} normal block at 0x03F3D970, 8 bytes long. Data: < w > D0 E5 F3 03 77 84 00 10 {93} normal block at 0x03F3E520, 2688 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 {91} normal block at 0x03F473B0, 336 bytes long. Data: <cccccccccccccccc> 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 Object dump complete.

That looks like what I'm after. Thanks.

I've taken a look at the terrain.shader that comes with Leadwerks to see if I can modify it to my needs, but I'm not sure where to start. What I want is to texture a grid mesh of a terrain with multiple textures based and height and slope, and maybe even an alpha map. If someone is able to point me in the right direction or even a small snippet of code that shows how the height and slope can change where a texture is shown I'd appreciate it. Thanks.

Thanks shadmar. I found adding the extra 8 verts in and updateing the AABB is good enough for now.

How can I manually change the min and max values of a models AABB? I've used the following code which seems to set the model->aabb okay but debugging the entity boxes doesn't show it and the model still disappears at the wrong times. model->aabb.min.x = -256.0; model->aabb.min.y = -256.0; model->aabb.min.z = -256.0; model->aabb.max.x = 256.0; model->aabb.max.y = 256.0; model->aabb.max.z = 256.0; model->aabb.Update();

I've noticed similar things with other models where a previously loaded texture applied to a totally different model will overlay onto it. Might be a bug... no sure.

I'd download in FBX. Just drop it into your models folder and it should convert to .mdl automatically. EDIT : You may have to setup a material for it though. The textures will convert when you place them in the folder too.

I have a problem with the geometry shader I'm working on. If someone could tell me why it works until I un-comment the line, RunLOD(4); That'd be great. The shader, material and a grid model is attached. Thanks. EDIT : Commenting out EmitVertex() solves the linking issue - but why? EDIT : If I'd only looked at the Error log I had hidden to the edge of the screen I would have see this; 2: Line 0: Hardware limitation reached, can only emit 60 vertices of this size Well that solves that.

Hello and welcome!

I second this. I'm always moving it out the way.

I agree. It would be nice if you could mouse over variables like C++ and see they're value. As for the above error, I think I've narrowed it down to removing a break-point while the program is running. The icon is removed but the program keeps breaking there.

Spent ages trying to figure out why a certain line of code keep breaking the program. After deciding to restart Leadwerks I reopened the script file and suddenly there was a break-point at that line. I did remove it before hand, but it obviously just removed the icon, not the actual break-point. Hope this can be resolved soon.

Commenting out, self:MakeNums(self.CurrentCode) in the update world loop stops the crash on the second time. But for the life of me I can't debug it with breakpoints. It's as if, with the function, it crashes second time around for a different reason? But without calling the function, it works... I'm going to need a coffee

Thanks for the help. I think I'll have to do it that way. Buffer Objects aren't big enough for my needs.

Does anyone know how to set a Uniform Buffer Object from c++? The Geometry shader has the following Buffer Object; layout(std140) uniform DataBlock { float terrainHeight[1024]; }; https://www.khronos.org/opengl/wiki/Uniform_Buffer_Object Not sure how to get the program ID from a shader in Leadwerks. Or will I have to use OpenGL commands directly?I I figured out how to at least get the Data Blocks index; Shader* sh = material->GetShader(); OpenGLShader* gl_sh = (OpenGLShader*)sh; unsigned int block_index = glGetUniformBlockIndex(gl_sh->program, "DataBlock"); if (block_index != GL_INVALID_INDEX) { //bind it here } This command gets the size (in bytes) that is available for each buffer; int size; glGetIntegerv(GL_MAX_UNIFORM_BLOCK_SIZE, &size); In this case it was 65,536 bytes. I think there is a max number of buffers allowed too.

I figured out how to do it now, thanks. It seems that gl_Position doesn't let the shader link when inside a loop that uses a uniform variable as a end condition. int current_level = 0; uniform int lod_level = 1; while(current_level < lod_level) { current_level++; gl_Position = pos; EmitVertex(); } This isn't all the code, but commenting out gl_positon or changing the while loop to; while(current_level < 2) will then work.

Thanks. I'll take a look.