[Physics Units of Measurement]

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.

[Terrain Texturing Shader]

Ahh thanks.  I'll check it out.

[Terrain Texturing Shader]

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.

[Terrain Texturing Shader]

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

[Terrain Texturing Shader]

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.

[Calculate Normal's from Heightmap]

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.

[Calculate Normal's from Heightmap]

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

[Calculate Normal's from Heightmap]

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.

[Calculate Normal's from Heightmap]

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.

[Calculate Normal's from Heightmap]

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.

[Vertex Normal Shader]

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

[Vertex Normal Shader]

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

[Vertex Normal Shader]

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

[Texture by height / slope]

That looks like what I'm after. Thanks.

[Texture by height / slope]

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.

[Manually Set AABB()]

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

[Manually Set AABB()]

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

[4.3 Transparent and Refraction shader bug ?]

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.

[Pistol model]

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.

[GLSL Geometry Shader Help Needed]

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!]

Hello and welcome!

[Dockable Script Editor]

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

[Lua Break-points not removing]

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.

[Lua Break-points not removing]

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.

[Issues with a keypad]

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