SpiderPig

Ah okay. Thanks for the explanation.

I tried that and and it seems to do the exact same thing. With the following code though, GetRotation(false) works but GetRotation(true) dosn't. I think the global xy & z will vary to the local rotation due to rotation on multiple axis's, but it shouldn't set to zero suddenly then back to some other number should it? Vec3 rot = box->GetRotation(); rot.x += 0.2f; rot.y += 0.2f; rot.z += 0.2f; box->SetRotation(rot); Time::Update(); world->Update(); world->Render(); context->SetBlendMode(Blend::Alpha); std::stringstream ss; ss << "rot = " << box->GetRotation().ToString(); context->DrawShadowText(ss.str(), 20, 20); ss.str(""); ss << "rot = " << box->GetRotation(true).ToString(); context->DrawShadowText(ss.str(), 20, 40);

When turning an entity, GetRotation() will return correct for a while then the Z axis will pop to zero for a bit before it starts reading properly again. Below is some test code showing the problem. On my current project, sometimes the Turn() function will suddenly pop to random values, but I'm unable to reproduce this here yet. I'm using the latest BETA build. #include "App.h" using namespace Leadwerks; App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; } Model* box; bool App::Start() { window = Window::Create("Turn Test",50,50, 1024, 768); window->Show(); context = Context::Create(window); world = World::Create(); DirectionalLight* light = DirectionalLight::Create(); light->SetRotation(35, 35, 35); Camera* camera = Camera::Create(); box = Model::Box(); box->Move(0, 0, 2); return true; } bool App::Loop() { if (window->KeyHit(Key::Escape) == true) { return false; } box->Turn(0.2, 0.2, 0.2); Time::Update(); world->Update(); world->Render(); context->SetBlendMode(Blend::Alpha); std::stringstream ss; ss << "rot = " << box->GetRotation().ToString(); context->DrawShadowText(ss.str(), 20, 20); context->Sync(true); return true; }

Awesome! After updating though I get the following error; Cannot open include file: 'isteamparentalsettings.h': No such file or directory In the "steam_api.h" file.

Lately I've been getting heaps of seemingly random errors. I traced a few of these problems to memory leaks which is why I started using smart pointers. But still I get random "Access Violations". Sometimes it will be inside a Leadwerks function and other times it will be in mine. I can stop the program and run again without cleaning the solution and it will crash somewhere else or it wont crash at all. Seems to be random and the only thing I think it could be is memory leaks. I'm not sure what else could cause random errors like this. Has anyone had similar problems or know of possible other causes / solutions?

Thanks for the reply. I'll make sure they're setup right now.

I just want to verify the way the physics commands should work. I'm assuming that Newton Game Dynamics uses real world equations to calculate the final force and velocity of objects. So if that's the case, what are the units of measurements that should be passed to each of the physics commands? If I set an entities mass to 100.0f, and say this is 100 kg, what should input into into "AddForce()"? m/s² or Newtons? It would make sense to be newtons because that's the measurement of force. And also "SetFriction()". Is this the friction coefficient or the force in newtons that has to be over come? Physics are not behaving the way I think they should in my game and I just want to make sure I'm feeding the commands the right values.

Ahh thanks. I'll check it out.

I have the shader now and am making it work with Leadwerks at the moment. What texture bindings are you referring to? More textures would be good.

Thanks Shadmar, the code helps a lot. I'm still looking for someone who can do it for me. I've posted the job on UpWork too. https://www.upwork.com/ab/applicants/866045947490144256/job-details

I'm looking for someone to write a terrain shader that will texture a terrain model based on height and slope. I want it to use uniforms for the height and slope of each layer so I can change them through code. It will need to use at least four layers - each with diffuse, normal and specular maps. If it can use more layers that would be better. Also I would like the option to use an alpha map to further control where textures are shown. The terrain is a cube, pictured below; Would like it by the end of the month if possible. Will pay for the work too. PM me if interested.

Thanks for the explanation it makes sense now. This is the code I use now for the normal; Vec3 Normal = Vec3(2.0*(center_r-center_l),2.0*(center_d-center_u),-4.0).Normalize(); I must be doing something else wrong somewhere though. This image is with the code above; And this image is with the command Surface->UpdateNormals() You can see the difference, the later being the desired result. I can see that the higher detailed mesh in the center of the terrain is pretty good in the first image as well as the second, but it's the lower detailed mesh that doesn't look great. Does the size of the LOD patches need to influence the length of the normal to get a softer transition? Or perhaps it's because I'm pre-calculating all the normal's for the different LOD levels and storing each LOD level in an array of Vec3's. One Vec3 for each vertex (or pixel of the height-map). This is the entire code for one 16 bit height-map; unsigned int total_indices = map_size * map_size; hills = (float*)malloc(total_indices * sizeof(float)); cFile* map = new cFile(); unsigned short* data_buffer = (unsigned short*)map->LoadBinary("Maps/Hills.r16", DATA_TYPE::UNSIGNED_SHORT); for (int e = 0; e < total_indices; e++) { hills[e] = data_buffer[e] * 0.00390625; } //this should be save as floats in a file //MAKE NORMAL BUFFERS FOR EACH LOD LEVEL////////////////////////////////////// int lod_levels = 7; int _skip_value[7] = { 1,2,4,8,16,32,64 }; n_x = (float**)malloc(_start_lod * sizeof(float)); n_y = (float**)malloc(_start_lod * sizeof(float)); n_z = (float**)malloc(_start_lod * sizeof(float)); for (int n_index = 0; n_index < 7; n_index++)//_start_lod { //perhaps make each array only the size of the vertexes needed int _lodsize = ((map_size - 1) / _skip_value[n_index]) + 1; n_x[n_index] = (float*)malloc(_lodsize*_lodsize * sizeof(float)); n_y[n_index] = (float*)malloc(_lodsize*_lodsize * sizeof(float)); n_z[n_index] = (float*)malloc(_lodsize*_lodsize * sizeof(float)); unsigned int id = 0, map_index = 0, current_index = 0; float center_l, center_r, center_u, center_d, center; Vec3 normal_buffer; //get the normals for each lod level? //int skip_value = (map_size - 1) / _lodsize; for (int y = 0; y < map_size; y += _skip_value[n_index]) { for (int x = 0; x < map_size; x += _skip_value[n_index]) { //if (x != 0 && x != map_size - 1 && y != 0 && y != map_size - 1) //{ //all the normals can be pre-calculated for speed increase //make a normal collection for each lod level current_index = (y * map_size) + x; center = HeightMaps->hills[current_index]; //HANDLE THE LEFT VERTEX////////////////////////////////////////// if (x == 0) { center_l = center; } else { map_index = (y * map_size) + (x - _skip_value[n_index]); center_l = HeightMaps->hills[map_index]; } ///////////////////////////////////////////////////////////////// if(x == (map_size - 1)){ center_r = HeightMaps->hills[current_index]; } else { map_index = (y * map_size) + (x + _skip_value[n_index]); center_r = HeightMaps->hills[map_index]; } if (y == 0) { center_d = HeightMaps->hills[current_index]; } else { map_index = ((y - _skip_value[n_index]) * map_size) + x; center_d = HeightMaps->hills[map_index]; } if (y == (map_size - 1)) { center_u = HeightMaps->hills[current_index]; } else { map_index = ((y + _skip_value[n_index]) * map_size) + x; center_u = HeightMaps->hills[map_index]; } normal_buffer = Vec3(2.0*(center_r-center_l),2.0*(center_d-center_u),-4.0).Normalize(); n_x[n_index][id] = normal_buffer.x; n_y[n_index][id] = normal_buffer.y; n_z[n_index][id] = normal_buffer.z; id++; } } } EDIT : I think I've found the issue. The problem was not setting the normal_buffer up to use the large distance between the vertices on the lower LOD levels. I used the following line and it looks good now; normal_buffer = Vec3(center_r-center_l, center_d-center_u,-(_skip_value[n_index]*10.0)).Normalize(); Multiplying by 10 made it less dark.

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();