Code: ETM Dynamic Lighting

SongOfTheWeave

17-04-2008 10:53:09

ETM Dynamic Lighting
With Normal Mapping and Point Light Attenuation
Last Modified: December 12, 2008

- 12/12/2008 -
Shaders modified to reflect changes in latest version of ETM.
Section on modifying ETM removed, modifications no longer necessary.

- 5/2008 -
There were more problems with the previous shaders than I care to recount. Here's new shaders that work properly. I've added attenuation for point lights as well. Look below for a package of normal maps for the ETM demo splatting textures too.



- From Original Post -
Since these topics seem to have converged and the old threads have a lot of bad code in them :oops: I'm making a new thread for "the new/good stuff." I'll edit this post with any changes and improvements so the newest stuff stays at the top and doesn't get lost in discussion below.

Normal Mapping Thread
Original Dynamic Lighting Thread

Features to Come:

At some point I'm going to modify these to do 3 lights per pass which will seriously help the speed. Especially in the normal mapping FP because for any given position it now needs to:

for each light
splat the normal maps
modify that value by the Tan/norm/binorm matrix
THEN do lighting
end for


when I write the multilight shader it'll be more like this:

for each group of 3 lights
splat the normal maps
modify that value by the Tan/norm/binorm matrix
then do lighting for the 1st light
then do lighting for the 2nd light
then do lighting for the 3rd light
end for


So, it will only have to mess with all those textures and the 3x3 matrix once every 3 lights, rather than having to do duplicate that work for each light.

Normal Maps for ETM Demo Textures

Zipped package of 6 png's

Assumptions & prerequisites:
  1. Y is up (ETM hardcoded convention)[/*:m]
  2. Normal maps (images) are Z up (Nvidia photoshop plugin spits them out this way)[/*:m]
  3. ETM must be set to calculate normals and tangents![/*:m][/list:u]

    CG Shaders:
    expand(float3) is a function used to expand the colour value from the normal map to the appropriate signed vector.
    ETAmbient_VS is a simple shader for the ambient pass.

    Dynamic lighting, no normal mapping
    ETDynLighting_vp is the VP for lighting w/o normal mapping. I did not write shaders for normal mapping that supported shaders < 2.0. I started to but it would have been so slow and ridiculous that no one with a card that didn't support shaders 2.0 would be able to run it at usable FPS. These are also available so that I can provide a "Terrain normal mapping on/off" switch to the user. These non-normal mapping lighting shaders are faster.
    ETDynLighting_fp is the FP for lighting w/o normal mapping

    Dynamic Lighting with normal mapping
    ETDynLightingNM_vp is the VP that does lighting and normal mapping woot!
    ETDynLightingNM_fp is the FP that does lighting and normal mapping. This is the heavy one. It is the only one that requires shaders 2.0


    // Expand a range-compressed vector
    float3 expand(float3 v)
    {
    return (v - 0.5) * 2;
    }

    void ETAmbient_VS
    (
    float4 position : POSITION,
    float delta : BLENDWEIGHT,

    uniform float4x4 worldViewProj,
    uniform float4 ambient,

    uniform float morphFactor,

    out float4 oPosition : POSITION,
    out float4 oColor : COLOR
    )
    {
    position.y = position.y + (delta.x * morphFactor);
    oPosition = mul(worldViewProj, position);
    oColor = ambient;
    }

    void ETDynLighting_vp
    (
    float4 position : POSITION,
    float3 normal : NORMAL,
    float delta : BLENDWEIGHT,

    uniform float4 lightPosition,
    uniform float3 eyePosition,
    uniform float4x4 worldviewproj,
    uniform float morphFactor,
    uniform float4 atten,

    out float4 oWorldPos : POSITION,

    out float3 oNorm : TEXCOORD0,
    out float3 oLightDir : TEXCOORD1,
    out float3 oEyeDir : TEXCOORD2,
    out float oLumin : TEXCOORD3
    )
    {
    position.y = position.y + (delta.x * morphFactor);
    oWorldPos = mul(worldviewproj, position);
    oNorm = normal;

    oLightDir = lightPosition.xyz - (position.xyz * lightPosition.w);

    float dist = length(oLightDir);
    oLumin = 1 / (atten.y + atten.z * dist + atten.w * dist * dist);
    oLumin = min(oLumin, 1.0);

    oEyeDir = normalize(eyePosition - position.xyz);
    oLightDir = normalize(oLightDir);
    }

    void ETDynLighting_fp
    (
    float3 normal : TEXCOORD0,
    float3 lightDir : TEXCOORD1,
    float3 eyeDir : TEXCOORD2,
    float lumin : TEXCOORD3,

    uniform float4 lightDiffuse,
    uniform float4 lightSpecular,
    uniform float exponent,

    out float4 oColor : COLOR
    )
    {
    normal = normalize(normal);

    lightDir = normalize(lightDir);
    eyeDir = normalize(eyeDir);
    float3 halfAngle = normalize(lightDir + eyeDir);

    float NdotL = dot(lightDir, normal);
    float NdotH = dot(halfAngle, normal);
    float4 Lit = lit(NdotL, NdotH, exponent);

    oColor = lumin * (lightDiffuse * Lit.y + lightSpecular * Lit.z * Lit.y);
    }


    void ETDynLightingNM_vp
    (
    float4 position : POSITION,
    float3 normal : NORMAL,
    float3 tangent : TANGENT,
    float2 uv : TEXCOORD0,
    float delta : BLENDWEIGHT,

    uniform float4 lightPosition,
    uniform float3 eyePosition,
    uniform float4x4 worldviewproj,
    uniform float morphFactor,
    uniform float4 atten,

    out float4 oWorldPos : POSITION,

    out float2 oUV : TEXCOORD0,
    out float3 oNorm : TEXCOORD1,
    out float3 oTangent : TEXCOORD2,
    out float3 oBinormal : TEXCOORD3,
    out float3 oLightDir : TEXCOORD4,
    out float3 oEyeDir : TEXCOORD5,
    out float oLumin : TEXCOORD6
    )
    {
    position.y = position.y + (delta.x * morphFactor);
    oWorldPos = mul(worldviewproj, position);
    oUV = uv;
    oNorm = normal;

    /* It is not neccessary to calculate tangents in the shader, ETM will calculate tangents for you and pass the values in to the TANGENT parameter. I leave the commented tangent calculation here so that in case you really want to calculate them in the shader for whatever reason, you have that option. -SotW 12/13/2008 */
    oTangent = tangent;
    //oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
    oBinormal = normalize(cross(tangent, normal));

    oLightDir = lightPosition.xyz - (position.xyz * lightPosition.w);

    float dist = length(oLightDir);
    oLumin = 1 / (atten.y + atten.z * dist + atten.w * dist * dist);
    oLumin = min(oLumin, 1.0);

    oEyeDir = normalize(eyePosition - position.xyz);
    oLightDir = normalize(oLightDir);
    }

    void ETDynLightingNM_fp
    (
    float2 uv : TEXCOORD0,
    float3 normal : TEXCOORD1,
    float3 tangent : TEXCOORD2,
    float3 binormal : TEXCOORD3,
    float3 lightDir : TEXCOORD4,
    float3 eyeDir : TEXCOORD5,
    float lumin : TEXCOORD6,

    uniform sampler2D covMap1,
    uniform sampler2D covMap2,
    uniform sampler2D splat1,
    uniform sampler2D splat2,
    uniform sampler2D splat3,
    uniform sampler2D splat4,
    uniform sampler2D splat5,
    uniform sampler2D splat6,

    uniform float splatScaleX,
    uniform float splatScaleZ,

    uniform float4 lightDiffuse,
    uniform float4 lightSpecular,
    uniform float exponent,

    out float4 oColor : COLOR
    )
    {
    float3 cov1 = tex2D(covMap1, uv).rgb;
    float3 cov2 = tex2D(covMap2, uv).rgb;
    uv.x *= splatScaleX;
    uv.y *= splatScaleZ;
    float3 normModifier = tex2D(splat1, uv) * cov1.x
    + tex2D(splat2, uv) * cov1.y
    + tex2D(splat3, uv) * cov1.z
    + tex2D(splat4, uv) * cov2.x
    + tex2D(splat5, uv) * cov2.y
    + tex2D(splat6, uv) * cov2.z;

    normModifier = normalize(expand(normModifier.xzy));

    // Form a rotation matrix out of the vectors
    tangent = normalize(tangent);
    binormal = normalize(binormal);
    normal = normalize(normal);
    float3x3 rotation = float3x3(tangent, normal, binormal);

    normModifier = mul(rotation, normModifier);
    normModifier = normalize(normModifier);

    lightDir = normalize(lightDir);
    eyeDir = normalize(eyeDir);
    float3 halfAngle = normalize(lightDir + eyeDir);

    float NdotL = dot(lightDir, normModifier);
    float NdotH = dot(halfAngle, normModifier);
    float4 Lit = lit(NdotL, NdotH, exponent);

    oColor = lumin * (lightDiffuse * Lit.y + lightSpecular * Lit.z * Lit.y);
    //oColor = lightDiffuse * Lit.y + lightSpecular * Lit.z * Lit.y;
    }


    Program File

    vertex_program ETAmbient_VS cg
    {
    source ETDynLighting.cg
    entry_point ETAmbient_VS
    profiles vs_1_1 arbvp1

    default_params
    {
    param_named_auto worldViewProj worldviewproj_matrix
    param_named_auto ambient ambient_light_colour
    param_named_auto morphFactor custom 77
    }
    }

    vertex_program ET/Programs/VSDynLighting cg
    {
    source ETDynLighting.cg
    entry_point ETDynLighting_vp
    profiles vs_1_1 arbvp1

    default_params
    {
    param_named_auto lightPosition light_position_object_space 0
    param_named_auto eyePosition camera_position_object_space
    param_named_auto worldviewproj worldviewproj_matrix
    param_named_auto morphFactor custom 77
    param_named_auto atten light_attenuation 0
    }
    }

    fragment_program ET/Programs/PSDynLighting cg
    {
    source ETDynLighting.cg
    entry_point ETDynLighting_fp
    profiles ps_2_0 arbfp1

    default_params
    {
    param_named_auto lightDiffuse light_diffuse_colour 0
    param_named_auto lightSpecular light_specular_colour 0
    param_named exponent float 63
    }
    }

    vertex_program ET/Programs/VSDynLightingNM cg
    {
    source ETDynLighting.cg
    entry_point ETDynLightingNM_vp
    profiles vs_1_1 arbvp1

    default_params
    {
    param_named_auto lightPosition light_position_object_space 0
    param_named_auto eyePosition camera_position_object_space
    param_named_auto worldviewproj worldviewproj_matrix
    param_named_auto morphFactor custom 77
    param_named_auto atten light_attenuation 0
    }
    }

    fragment_program ET/Programs/PSDynLightingNM cg
    {
    source ETDynLighting.cg
    entry_point ETDynLightingNM_fp
    profiles ps_2_0 arbfp1

    default_params
    {
    param_named_auto lightDiffuse light_diffuse_colour 0
    param_named_auto lightSpecular light_specular_colour 0
    param_named exponent float 63
    param_named splatScaleX float 20
    param_named splatScaleZ float 20
    }
    }


    Material

    Notes:
    1. My texture units for splatting and normal mapping passes are added at runtime because they vary depending on what textures the terrain that's being loaded uses. If you just want to get this running with the 6 ETM demo textures, add in the texture units to the splatting passes as per the ETM 2.2 distrib terrain material. Also add the normal maps to the lighting pass (I named the normal maps identically but with "_norm" added before the extension.)[/*:m][/list:u]

      material ETTerrainMaterial
      {
      technique
      {
      pass Ambient
      {
      vertex_program_ref ETAmbient_VS
      {
      }
      }

      pass Lighting
      {
      scene_blend add
      iteration once_per_light

      vertex_program_ref ET/Programs/VSDynLightingNM
      {
      }

      fragment_program_ref ET/Programs/PSDynLightingNM
      {
      }
      }

      // primary splatting technique, requires PS 2.0
      pass Splatting
      {
      scene_blend modulate

      vertex_program_ref ET/Programs/VSLodMorph2
      {
      }

      fragment_program_ref ET/Programs/PSSplat2
      {
      param_named splatScaleX float 20
      param_named splatScaleZ float 20
      }
      }
      }
      }

tymo

17-04-2008 18:28:13

Well, I tested all possibilities with your shader's on my app.
I'm running it on Windows, copiling with GCC and my card is 8600GT.

Note that i haven't modified ETM to calculate tangents,
i modified the shader to calculate it...

void ETDynLightingNM_vp
(
float4 position : POSITION,
float3 normal : NORMAL,
//float3 tangent : TANGENT,
float2 uv : TEXCOORD0,
float delta : BLENDWEIGHT,

uniform float4 lightPosition,
uniform float3 eyePosition,
uniform float4x4 worldviewproj,
uniform float morphFactor,
uniform float4 atten,

out float4 oWorldPos : POSITION,

out float2 oUV : TEXCOORD0,
out float3 oNorm : TEXCOORD1,
out float3 oTangent : TEXCOORD2,
out float3 oBinormal : TEXCOORD3,
out float3 oLightDir : TEXCOORD4,
out float3 oEyeDir : TEXCOORD5,
out float oLumin : TEXCOORD6
)
{
position.y = position.y + (delta.x * morphFactor);
oWorldPos = mul(worldviewproj, position);
oUV = uv;
oNorm = normal;
//oTangent = tangent;
oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
//oBinormal = normalize(cross(tangent, normal));
oBinormal = normalize(cross(oTangent, normal));

oLightDir = lightPosition.xyz - (position.xyz * lightPosition.w);

float dist = length(oLightDir);
oLumin = 1 / (atten.y + atten.z * dist + atten.w * dist * dist);
oLumin = min(oLumin, 1.0);

oEyeDir = normalize(eyePosition - position.xyz);
oLightDir = normalize(oLightDir);
}


Here's what i got:

-------------------------------------------------------------------------
First test setup: Diret3D9, VSDynLightingNM, PSDynLightingNM.
I got an error on ogre startup log.

13:30:21: OGRE EXCEPTION(7:InternalErrorException): Unable to compile Cg program ET/Programs/PSDynLighting: CG ERROR : The compile returned an error.
(169) : warning C7011: implicit cast from "float4" to "float3"
(72) : error C3004: function "normalize" not supported in this profile
(74) : error C3004: function "normalize" not supported in this profile
(75) : error C3004: function "normalize" not supported in this profile
(76) : error C3004: function "normalize" not supported in this profile
(80) : error C3004: function "lit" not supported in this profile
in CgProgram::loadFromSource at D:\ogre-win32-v1-4-7\PlugIns\CgProgramManager\src\OgreCgProgramManagerDll.cpp (line 66)
13:30:21: High-level program ET/Programs/PSDynLighting encountered an error during loading and is thus not supported.
OGRE EXCEPTION(7:InternalErrorException): Unable to compile Cg program ET/Programs/PSDynLighting: CG ERROR : The compile returned an error.
(169) : warning C7011: implicit cast from "float4" to "float3"
(72) : error C3004: function "normalize" not supported in this profile
(74) : error C3004: function "normalize" not supported in this profile
(75) : error C3004: function "normalize" not supported in this profile
(76) : error C3004: function "normalize" not supported in this profile
(80) : error C3004: function "lit" not supported in this profile
in CgProgram::loadFromSource at D:\ogre-win32-v1-4-7\PlugIns\CgProgramManager\src\OgreCgProgramManagerDll.cpp (line 66)


Fixed this by changing the fragment profiles to ps_2_0.

The app runs ok, but lights do not affect the terrain, and no
normal maps.

-------------------------------------------------------------------------

Second test setup: OpenGL, VSDynLightingNM, PSDynLightingNM.

Everything works, lights, attenuation and normal map :D

-------------------------------------------------------------------------

Third test setup: OpenGL, VSDynLighting, PSDynLighting.

Works fine! Lights iluminate the terrain properly. Attenuation also works :)

-------------------------------------------------------------------------

Fourth test setup: Direct3D9, VSDynLighting, PSDynLighting.

App runs, but light has no effect on the terrain. :?

-------------------------------------------------------------------------

[Edit]
I edited the whole post, because on the first time i tested i used a incorrect version of gcc to compile the code. :oops:

SongOfTheWeave

18-04-2008 03:06:54

Looks like it doesn't work on DirectX... I'd be happy to hear any theories.

As for modifying ETM to calculate tangents, I just added instructions to do so in the top post.

NoodlesOnMyBack

11-05-2008 11:52:49

I just added the shaders to my project and im so happy that they work so nice! With my Athlon +3000 and GeForce 6600GT i have around 120 fps wich is more than good IMO
Thank you once again! :D

NoodlesOnMyBack

16-05-2008 03:09:02

Hi! Im bumping this thread again :lol:
The shaders are working like a charm, but i have some doubts/questions.
Im really new to cg, so correct me if im mistaken.

1)I understand that since ETM deforms the terrain in real time, you had to modifiy the code to calculate the tangent vectors.But what if my game doesnt need real time deformation?
Is it possible to change the shaders to use world-space/object-space tangents and see a noticeable performance boost?
I could also keep both techniques, one for the editor and the other for the game itself, wich will have a static terrain.
Am i missing something here?

2)Isnt it more efficient to use a vertex program to calculate the tangents?

SongOfTheWeave

16-05-2008 03:22:36

I think you are missing something here, but I'm not entirely sure what it is..

1)I understand that since ETM deforms the terrain in real time, you had to modifiy the code to calculate the tangent vectors.But what if my game doesnt need real time deformation?

In my version of the shaders, they don't calculate the tangents. ETM calculates the tangents when the mesh is created or changed (so they're not recalculated unless the mesh is changed.)

You have to modify ETM to calculate tangents though as I explain in the OP.

A subsequent posted provided a version of the shader that calculates the tangents in the vertex shader. This is less efficient.

Is it possible to change the shaders to use world-space/object-space tangents and see a noticeable performance boost?

Not sure what you mean. Something has to calculate the tangents. Your choices are to do it in ETM or in the shader. Having ETM do it is smarter because then they only have to be recalculated when the mesh is modified.

2)Isnt it more efficient to use a vertex program to calculate the tangents?

As opposed to what?

It's much less efficent than calculating them in ETM and more efficient than calculating them in the fragment program.

[edit]
I AM calculating the binormal in the vertex program, which could be delegated to ETM for a performance boost. In fact, I wrote code to do this, but it looks wrong, so I must have a mistake somewhere. So I calculate the binormals in the vertex program because I haven't worked on tracking down my error yet.

Hi! Im bumping this thread again :lol:
The shaders are working like a charm, but i have some doubts/questions.
Im really new to cg, so correct me if im mistaken.

1)I understand that since ETM deforms the terrain in real time, you had to modifiy the code to calculate the tangent vectors.But what if my game doesnt need real time deformation?
Is it possible to change the shaders to use world-space/object-space tangents and see a noticeable performance boost?
I could also keep both techniques, one for the editor and the other for the game itself, wich will have a static terrain.
Am i missing something here?

2)Isnt it more efficient to use a vertex program to calculate the tangents?

NoodlesOnMyBack

16-05-2008 03:42:44

Wow, that was fast.
Ok, so i was totally wrong :) Thanks for fixing the mess in my head.

Im still experimenting with some values in my game, can you give me some hints to make the "bumpiness" look better/different? Like, what to tweak in the lights and in the normal maps images. What tools do you use, etc.

SongOfTheWeave

16-05-2008 03:52:01

Wow, that was fast.
Ok, so i was totally wrong :) Thanks for fixing the mess in my head.

Im still experimenting with some values in my game, can you give me some hints to make the "bumpiness" look better/different? Like, what to tweak in the lights and in the normal maps images. What tools do you use, etc.


Some of the problems you run into doing this is that EVERYTHING IN THE WORLD uses Z up *Gives CABAListic the evil eye.* and ETM uses Y up.

(just teasing you CABAL)

I use the nvidia normal mapping photoshop plugin to create normal maps but I had screw with it a lot to figure out which way to swap the axis so that it worked right (rocks bumped up, rather than bumping in or other weird things.) It's not great but it's free. You can find it on the nvidia site somewhere (I don't have a link handy.)

[edit]
One of the things to tweak along with the axis stuff in the nvidia plugin is the "depth" parameter (don't recall exactly what the parameter is called.) I think I ended up using something like.. 16 for my terrain, which I thought was really high. Also if you have images that result in really fine grain noisy normal maps, run a small gaussian blur over the image prior to running the normal map filter over it. The result will hold together better as a normal map. (Obviously, don't save the blurred version, just use the original image as the diffuse tex.)
[/edit]

Crazybump is a sweet tool for generating normal maps but it is non-free ($99 personal license $299 commercial license)

SongOfTheWeave

21-05-2008 10:40:37

Change log May 21, 2008
  1. Added a modification to the profiles in the program file that makes it work under d3d9 for me.[/*:m]
  2. Removed fallback pass, it was lame. These lighting techniques require ps_2_0 or arbfp1 anyway so it was kinda pointless (since if you have ps_2_0 support you can do splatting in 1 pass anyway.)[/*:m]
  3. Removed references to the decal from material file. There's no reason you have to use it with this and the new version of the decal adds it's own pass anyway.[/*:m]
  4. Removed binormal calculation from ETDynLightingNM_vp and used ETM to pass in the binormal. Not sure why I didn't do this before, it was retarded not to.[/*:m][/list:u]

SongOfTheWeave

28-05-2008 03:20:53

I recommend that all users of this code follow the instructions in the OP to calculate binormals in the vertex shader. The modifications to ETM I outline in the OP calculate the binormal incorrectly.

I would very much appreciate if someone could point out my mistake ;)

arete

17-07-2008 18:33:38

Hi!

I have some problems with this normal mapping shader. The shader code is unmodified except for binormal calculation (just like tymo did above). I modified the material file to contain normal map texture units.

This screenshot shows the problem. As you can see, it's messed up. There's some reflections from red light but they don't seem right. The red spots (or "tiles") move as i move the camera.



Here's another shot with a mesh and terrain material attached to it. The white "tiles" on athene shows only if camera is in certain position and angle.



(I know that splatting is also messed up but I'm not concerned about that because the terrain lighting isn't working even if I use my own shader).

I'm using latest version of MET in Mogre 1.4.6. Does anyone have same kind of problems or does anyone have an idea to fix this?

SongOfTheWeave

23-07-2008 22:41:47

The easy issue first: The terrain material SHOULD fail (not sure if it should throw an exception or just yield incorrect results) when you place it on any other mesh. The manual shader params that ETM sets on the terrain MObs wont be set on any other mesh. Actually, it makes sense that you're getting strange surface deformations because the LOD computations in the vertex programs will have junk passed into them. I'm not sure if an unset custom vertex program parameter is passed to the VP as 0 or as an uninitialised value. So, yeah, that shouldn't work.

As for the other issue:
Which of my shaders are you using?

Also, if splatting isn't working, normal mapping wont work right either. Normal mapping splats the normal maps in the same way that regular splatting does. It just uses them for lighting calculations rather than diffuse colouring. So, if your coverage maps or some other splatting related item is borked, normal mapping will be borked too.

It looks like your splatting scale is very large, but perhaps that is intentional.

My advice is to get splatting working, then if normal mapping still isn't working, I would probably look at the normal map textures and make sure they're generated correctly.

DannyZB

25-07-2008 17:43:18

This thing is confusing the hell out of me ..

I followed the exact instructions and I'm getting a completely black terrain.

What did I miss?
I didn't get how I can programatically set the splatting textures in this way in the first place.

If it's not obvious yet ,I have 0 shader experience and I just improvise where I can , but this is too much

SongOfTheWeave

29-07-2008 22:08:37

This thing is confusing the hell out of me ..

I followed the exact instructions and I'm getting a completely black terrain.

What did I miss?
I didn't get how I can programatically set the splatting textures in this way in the first place.

If it's not obvious yet ,I have 0 shader experience and I just improvise where I can , but this is too much


Try getting splatting to work properly with the shaders that are a part of the ETM release, in otherwords, without dynamic lighting and without normal mapping.

That will cut down on the number of things you need to worry about and getting these shaders to work depends upon the basics already working.

If you don't have that working, you should start a new thread to ask general questions about how to get ETM to work. Your problem seems to be not knowing how to use ETM, not a problem with the shaders themselves. Look back to the ETM demo as a reference on how to set up the terrain manager and splatting manager.

DannyZB

01-08-2008 22:12:08

Thats exactly the point
My code works perfectly with lightmaps

whats the main difference in this shader that causes the terrain to become totally black if I use the exact same code I used for the original shaders?

SongOfTheWeave

01-08-2008 23:35:29

Thats exactly the point
My code works perfectly with lightmaps

whats the main difference in this shader that causes the terrain to become totally black if I use the exact same code I used for the original shaders?


You had said previously that your splatting was messed up. Is it?

Also, the lightmap technique does not require any lights in the scene. The dynamic lighting technique does.

What is your scene ambient colour? If there are no lights and the ambient colour is black, the terrain will be black.

Have you checked your ogre log? Weird things may happen if your GPU doesn't support the needed shader profiles.

Did you remove the lightmap pass from the terrain material?

DannyZB

02-08-2008 10:45:55


You had said previously that your splatting was messed up. Is it?

Also, the lightmap technique does not require any lights in the scene. The dynamic lighting technique does.

What is your scene ambient colour? If there are no lights and the ambient colour is black, the terrain will be black.

Have you checked your ogre log? Weird things may happen if your GPU doesn't support the needed shader profiles.

Did you remove the lightmap pass from the terrain material?



- I used your shader , it doesn't have a lightmap pass.
- I set up dynamic lights and ambient colour
- GPU - RX800Pro

SongOfTheWeave

04-08-2008 06:13:24


- GPU - RX800Pro


I don't know what this is. You need to look up if it supports the required profiles which are:
Vertex Program Profiles
DirectX: vs_1_1
OpenGL: arbvp1
Fragment Program Profiles
DirectX: ps_2_0
OpenGL: arbfp1

As I said previously, you also need to check your ogre log, it will mention any errors of this nature.

From the information you've given me, I can't tell you what the problem is. Discovering the point of failure will require a bit of detective work. A bit of advice (learned by painful experience): The longer it takes to find an error, the stupider it tends to be because we tend to check the "smart" mistakes first.

DannyZB

04-08-2008 21:13:54

Say what makes a terrain look black ..
I set the ambient colour to 1.0 1.0 1.0

Doesn't that mean lighting should have no effect?

I'd say it's a problem with the splatting ..
but what does the black color mean anyway?

Dutchie

13-08-2008 14:27:29

I am also having this problem with the black terrain. I think it is because of the textures. There is no place anymore that points to which textures to use. If i just add:


texture_unit
{
texture splatting0.png
}


and all the other splatting textures the terrain changes, but still not good.
How do you add the textures SongOfTheWeave?

cmk524

14-08-2008 11:09:20

Iam new to ogre

As u told that up to program i had written well.

ETerrainManager also build success.

but iam having doubt where should i include material code

-I hade to add to existing one or replace.

plz tell me
on replacing iam getting black terrain

then how to write that material file

Nauk

14-08-2008 21:11:50

thanks for sharing SoTW :) looking forward to toy around with it on the weekend.

SongOfTheWeave

14-08-2008 22:29:14

If you think you are having a material/texture unit problem, please post the .material file that you are using. I can't tell what what might be wrong without seeing it.

As I mentioned before, in my project, I create the material for my terrain in code so that I can dynamically add/remove texture units and passes depending on the settings of the game options.

IFASS

16-08-2008 17:52:59

Hm, we encountered a problem when upgrading ETM to contain your changes. We use stock ETM2.2 with your changes.

Ogre log:
http://rafb.net/p/AHAWo681.html

Error:

OGRE EXCEPTION(3:RenderingAPIException): Cannot assemble D3D9 shader ET/Programs/PSDynLightingNM Errors:
(69): error X5775: Dependent tex-op sequence too long (4th order). A 1st order dependent tex-op is a tex[ld*|kill] instruction in which either: (1) an r# reg is input (NOT t# reg), or (2) output r# reg was previously written, now being written AGAIN. A 2nd order dependent tex-op occurs if: a tex-op reads OR WRITES to an r# reg whose contents, BEFORE executing the tex-op, depend (perhaps indirectly) on the outcome of a 1st order dependent tex-op. An (n)th order dependent tex-op derives from an (n-1)th order tex-op. A given tex-op may be dependent to at most 3rd order (ps_2_0/x only).
(71): error X5775: Dependent tex-op sequence too long (5th order). A 1st order dependent tex-op is a tex[ld*|kill] instruction in which either: (1) an r# reg is input (NOT t# reg), or (2) output r# reg was previously written, now being written AGAIN. A 2nd order dependent tex-op occurs if: a tex-op reads OR WRITES to an r# reg whose contents, BEFORE executing the tex-op, depend (perhaps indirectly) on the outcome of a 1st order dependent tex-op. An (n)th order dependent tex-op derives from an (n-1)th order tex-op. A given tex-op may be dependent to at most 3rd order (ps_2_0/x only).
(73): error X5775: Dependent tex-op sequence too long (6th order). A 1st order dependent tex-op is a tex[ld*|kill] instruction in which either: (1) an r# reg is input (NOT t# reg), or (2) output r# reg was previously written, now being written AGAIN. A 2nd order dependent tex-op occurs if: a tex-op reads OR WRITES to an r# reg whose contents, BEFORE executing the tex-op, depend (perhaps indirectly) on the outcome of a 1st order dependent tex-op. An (n)th order dependent tex-op derives from an (n-1)th order tex-op. A given tex-op may be dependent to at most 3rd order (ps_2_0/x only).
(75): error X5775: Dependent tex-op sequence too long (7th order). A 1st order dependent tex-op is a tex[ld*|kill] instruction in which either: (1) an r# reg is input (NOT t# reg), or (2) output r# reg was previously written, now being written AGAIN. A 2nd order dependent tex-op occurs if: a tex-op reads OR WRITES to an r# reg whose contents, BEFORE executing the tex-op, depend (perhaps indirectly) on the outcome of a 1st order dependent tex-op. An (n)th order dependent tex-op derives from an (n-1)th order tex-op. A given tex-op may be dependent to at most 3rd order (ps_2_0/x only).


ETTerrain.material

material ETTerrainMaterial
{
technique
{
pass Ambient
{
vertex_program_ref ETAmbient_VS
{
}
}

pass Lighting
{
scene_blend add
iteration once_per_light

vertex_program_ref ET/Programs/VSDynLightingNM
{
}

fragment_program_ref ET/Programs/PSDynLightingNM
{
}
texture_unit
{
texture splatting0_norm.png
}
texture_unit
{
texture splatting1_norm.png
}
texture_unit
{
texture splatting2_norm.png
}
texture_unit
{
texture splatting3_norm.png
}
texture_unit
{
texture splatting4_norm.png
}
texture_unit
{
texture splatting5_norm.png
}
}

// primary splatting technique, requires PS 2.0
pass Splatting
{
scene_blend modulate

vertex_program_ref ET/Programs/VSLodMorph2
{
}

fragment_program_ref ET/Programs/PSSplat2
{
param_named splatScaleX float 20
param_named splatScaleZ float 20
}
texture_unit
{
// first coverage map, dynamically managed
texture ETSplatting0
}
texture_unit
{
// second coverage map, dynamically managed
texture ETSplatting1
}

// splatting textures
texture_unit
{
texture splatting0.png
}
texture_unit
{
texture splatting1.png
}
texture_unit
{
texture splatting2.png
}
texture_unit
{
texture splatting3.png
}
texture_unit
{
texture splatting4.png
}
texture_unit
{
texture splatting5.png
}
}
}
}


ETTerrain.program

vertex_program ETAmbient_VS cg
{
source ETDynLighting.cg
entry_point ETAmbient_VS
profiles vs_1_1 arbvp1

default_params
{
param_named_auto worldViewProj worldviewproj_matrix
param_named_auto ambient ambient_light_colour
param_named_auto morphFactor custom 77
}
}

vertex_program ET/Programs/VSDynLighting cg
{
source ETDynLighting.cg
entry_point ETDynLighting_vp
profiles vs_1_1 arbvp1

default_params
{
param_named_auto lightPosition light_position_object_space 0
param_named_auto eyePosition camera_position_object_space
param_named_auto worldviewproj worldviewproj_matrix
param_named_auto morphFactor custom 77
param_named_auto atten light_attenuation 0
}
}

fragment_program ET/Programs/PSDynLighting cg
{
source ETDynLighting.cg
entry_point ETDynLighting_fp
profiles ps_2_0 arbfp1

default_params
{
param_named_auto lightDiffuse light_diffuse_colour 0
param_named_auto lightSpecular light_specular_colour 0
param_named exponent float 63
}
}

vertex_program ET/Programs/VSDynLightingNM cg
{
source ETDynLighting.cg
entry_point ETDynLightingNM_vp
profiles vs_1_1 arbvp1

default_params
{
param_named_auto lightPosition light_position_object_space 0
param_named_auto eyePosition camera_position_object_space
param_named_auto worldviewproj worldviewproj_matrix
param_named_auto morphFactor custom 77
param_named_auto atten light_attenuation 0
}
}

fragment_program ET/Programs/PSDynLightingNM cg
{
source ETDynLighting.cg
entry_point ETDynLightingNM_fp
profiles ps_2_0 arbfp1

default_params
{
param_named_auto lightDiffuse light_diffuse_colour 0
param_named_auto lightSpecular light_specular_colour 0
param_named exponent float 63
param_named splatScaleX float 20
param_named splatScaleZ float 20
}
}

fragment_program ET/Programs/PSSplat cg
{
source PSSplat.cg
entry_point main
profiles ps_1_1 arbfp1
}

fragment_program ET/Programs/PSSplat2 cg
{
source PSSplat2.cg
entry_point main
profiles ps_2_0 arbfp1
}

vertex_program ET/Programs/VSLodMorph cg
{
source VSLodMorph.cg
entry_point terrain_vp
profiles vs_1_1 arbvp1

default_params
{
param_named_auto morphFactor custom 77
param_named_auto worldViewProj worldviewproj_matrix
}
}

vertex_program ET/Programs/VSLodMorph2 cg
{
source VSLodMorph.cg
entry_point terrain_vp
profiles vs_1_1 arbvp1

default_params
{
param_named_auto morphFactor custom 77
param_named_auto worldViewProj worldviewproj_matrix
}
}

SongOfTheWeave

17-08-2008 05:09:56

Hm, we encountered a problem when upgrading ETM to contain your changes. We use stock ETM2.2 with your changes.

-Long Post Body Snipped-


That's an interesting error. I've never seen that one before. I'm not even entirely sure what it means, except that it's a CG compile error.

That tells us a few things about what isn't causing it. It isn't a problem with ETM, since it threw the exception in the resource init phase.

Looking through your log, there are quite a few other errors prior to the fatal error. I think if I were tackling this error, I'd go through and try to correct some of the "negligible" errors that happen before the fatal error on the off chance that the fatal error might be the result of "error accumulation" (that's not a technical term.) Also it makes sure that you're only looking at the relevant errors, and plus, it's good to get around to it at some point.

---- SOLUTION ----

Oh!! Duh, you need the coverage maps in the lighting pass too. They should be the first two texture units.

Heh, I should have seen that sooner.

IFASS

17-08-2008 09:49:04


---- SOLUTION ----

Oh!! Duh, you need the coverage maps in the lighting pass too. They should be the first two texture units.

Heh, I should have seen that sooner.


Unfortunately that didn't work. I have cleaned up all the error messages and added the coverage maps too the lightingpass, see:

Log: http://rafb.net/p/g9pj9162.html

Material:

material ETTerrainMaterial
{
technique
{
pass Ambient
{
vertex_program_ref ETAmbient_VS
{
}
}

pass Lighting
{
scene_blend add
iteration once_per_light

vertex_program_ref ET/Programs/VSDynLightingNM
{
}

fragment_program_ref ET/Programs/PSDynLightingNM
{
}

texture_unit
{
// first coverage map, dynamically managed
texture ETSplatting0
}
texture_unit
{
// second coverage map, dynamically managed
texture ETSplatting1
}

texture_unit
{
texture splatting0_norm.png
}
texture_unit
{
texture splatting1_norm.png
}
texture_unit
{
texture splatting2_norm.png
}
texture_unit
{
texture splatting3_norm.png
}
texture_unit
{
texture splatting4_norm.png
}
texture_unit
{
texture splatting5_norm.png
}
}

// primary splatting technique, requires PS 2.0
pass Splatting
{
scene_blend modulate

vertex_program_ref ET/Programs/VSLodMorph2
{
}

fragment_program_ref ET/Programs/PSSplat2
{
param_named splatScaleX float 20
param_named splatScaleZ float 20
}
texture_unit
{
// first coverage map, dynamically managed
texture ETSplatting0
}
texture_unit
{
// second coverage map, dynamically managed
texture ETSplatting1
}

// splatting textures
texture_unit
{
texture splatting0.png
}
texture_unit
{
texture splatting1.png
}
texture_unit
{
texture splatting2.png
}
texture_unit
{
texture splatting3.png
}
texture_unit
{
texture splatting4.png
}
texture_unit
{
texture splatting5.png
}
}
}
}


Also note that using
vertex_program_ref ET/Programs/VSDynLighting
fragment_program_ref ET/Programs/PSDynLighting

does not crash.

I also found a few links on the subject, maybe it's of any help.
DirectXDev, seems about ps2.0 limitation?
Steve Streeting Blog
[url=http://www.gpgpu.org]www.gpgpu.org

IFASS

17-08-2008 10:39:17

Ok, some progress from my side.. it seems that it has to do with the profiles limitation.
I have a ATI Radeon Mobility x1400 and a Intel T2500 (CoreDuo) @ 2.0ghz

vs_1_1 with ps_2_0 doesn't work at all, gives:

error X5775: Dependent tex-op sequence too long (4th order). A 1st order dependent tex-op is a tex[ld*|kill] instruction in which either: (1) an r# reg is input (NOT t# reg), or (2) output r# reg was previously written, now being written AGAIN. A 2nd order dependent tex-op occurs if: a tex-op reads OR WRITES to an r# reg whose contents, BEFORE executing the tex-op, depend (perhaps indirectly) on the outcome of a 1st order dependent tex-op. An (n)th order dependent tex-op derives from an (n-1)th order tex-op. A given tex-op may be dependent to at most 3rd order (ps_2_0/x only).

log: http://rafb.net/p/g9pj9162.html

vs_1_1 with ps_2_x compiles, but has a weird graphical error:

log: http://rafb.net/p/IN41yk91.html

Seeing this distortion, i figured it could be vertexshader related, so i tried vs_2_x

vs_2_x with ps_2_x seems to work fine

log: http://rafb.net/p/1axrQF53.html

SongOfTheWeave

17-08-2008 10:50:46

Try using ps_2_x as the profile for the NM fragment program rather than ps_2_0.

I -may- have been using OpenGL while I was using these exact shaders (I'm not using any of the ones exactly as posted anymore) and it's possible I didn't notice a D3D bug. Or it might be that there's a grey area in ps_2_0 that my card (nvidia 7600) implemented and some others didn't until one of the subsequent versions.

Let me know if that works for you, if not I'll give it a more thorough look over tomorrow when I'm more rested (my synapses begin to fire slowly at this hour in the early morning).

If this solves the bug for you I'll modify the .program file in the OP to reflect the change.

If it doesn't fix it, what version of ogre are you using? I don't -think- this should matter, but I didn't recognize the way the shader error was written so I was wondering if it's a different type of error, or the same type written differently in a different version of ogre. I seem to recall shader errors usually saying something like CG compile error. I'm using the current stable Eihort release.

SongOfTheWeave

17-08-2008 10:55:43

Ok, some progress from my side.. it seems that it has to do with the profiles limitation.
I have a ATI Radeon Mobility x1400 and a Intel T2500 (CoreDuo) @ 2.0ghz


Ah Hah! You beat me to it!

I was beginning to wonder if you had an ATI. I bet this is a disagreement between ATI and Nvidia over exactly what was implemented in ps_2_0.

You may be able to get it to work using vs_2_0 for the vert shader. It would be good to know what the minimum reqs for this are on an ATI card. Let me know the lowest profiles you can get it to run right with are and I'll update the OP with those profiles.

[edit]
Nice detective work btw, and now you've got the added bonus of having cleaned out all those other errors heh :)
[/edit]

IFASS

17-08-2008 11:08:05

Thanks :)

The lowest requirements I could find are:
vs_2_0
ps_2_x

I haven't tried it with any lights yet. I'm using ogre 1.4.7

IFASS

17-08-2008 11:55:35

One more question, what do i have to do to make the light have more effect on the terrain? For example, caelum sun, works fine with the terrain, lit at day, dark at night. Although what if i want it a little more lighter? The exponent factor doesn't seem to have any effect. Or would increasing the sun strength be a better idea?

SongOfTheWeave

17-08-2008 22:51:07

One more question, what do i have to do to make the light have more effect on the terrain? For example, caelum sun, works fine with the terrain, lit at day, dark at night. Although what if i want it a little more lighter? The exponent factor doesn't seem to have any effect. Or would increasing the sun strength be a better idea?

That depends on how you have your "sun" light set up. Assuming that your sun is a directional light, there is no attenuation because conceptually directional lights have no position, just a direction that is constant throughout the scene. If you want the unlit portions of your terrain to be less dark you can brighten the scene ambient colour.

"Strength" isn't a property of Ogre::Light and I don't know how Caelum implements its sun, so I can't help you there.

cmk524

01-09-2008 10:22:00

I got the single light dynamically.
how to put multiple lights and types spot,position ambigient

SongOfTheWeave

04-09-2008 21:24:51

I got the single light dynamically.
how to put multiple lights and types spot,position ambigient


You're going to have to phrase your question more intelligibly. I don't know what you're saying.

cmk524

05-09-2008 07:41:45

I ETTerrain

For dynamic light I had written tangent methods inET.

I changed shader files and normaps inserted.

as suggestions give in this forum.

I created single light in the scene it's working fine.

while creating another light. 2nd light doesn't effect the terrain.

First ie light0 is working fine.



/////////////////////////////////////

then I added the code in cg file

vertex_program ET/Programs/VSDynLightingNM cg
{
source ETDynLighting.cg
entry_point ETDynLightingNM_vp
profiles vs_1_1 arbvp1

default_params
{
param_named_auto lightPosition light_position_object_space 0
////light 2
param_named_auto lightPosition light_position_object_space 1

param_named_auto eyePosition camera_position_object_space
param_named_auto worldviewproj worldviewproj_matrix
param_named_auto morphFactor custom 77
param_named_auto atten light_attenuation 0
}
}

fragment_program ET/Programs/PSDynLightingNM cg
{
source ETDynLighting.cg
entry_point ETDynLightingNM_fp
profiles ps_2_0 arbfp1

default_params
{
param_named_auto lightDiffuse light_diffuse_colour 0
param_named_auto lightSpecular light_specular_colour 0
//for light 2
param_named_auto lightDiffuse light_diffuse_colour 1
param_named_auto lightSpecular light_specular_colour 1
param_named exponent float 63
param_named splatScaleX float 20
param_named splatScaleZ float 20
}
}






///cg file i changed
void ETDynLightingNM_vp
(
float4 position : POSITION,
float3 normal : NORMAL,
float3 tangent : TANGENT,
float3 binormal : BINORMAL,
float2 uv : TEXCOORD0,
float delta : BLENDWEIGHT,

uniform float4 lightPosition,
uniform float4 lightPosition1,

uniform float3 eyePosition,
uniform float4x4 worldviewproj,
uniform float morphFactor,
uniform float4 atten,

out float4 oWorldPos : POSITION,

out float2 oUV : TEXCOORD0,
out float3 oNorm : TEXCOORD1,
out float3 oTangent : TEXCOORD2,
out float3 oBinormal : TEXCOORD3,
out float3 oLightDir : TEXCOORD4,
out float3 oLightDir : TEXCOORD5,

out float3 oEyeDir : TEXCOORD6,
out float oLumin : TEXCOORD7 ,
out float oLumin1 : TEXCOORD8
)
{
position.y = position.y + (delta.x * morphFactor);
oWorldPos = mul(worldviewproj, position);
oUV = uv;
oNorm = normal;
oTangent = tangent;
//oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
oBinormal = binormal;
//oBinormal = normalize(cross(tangent, normal));

oLightDir = lightPosition.xyz - (position.xyz * lightPosition.w);
oLightDir1 = lightPosition1.xyz - (position.xyz * lightPosition.w);

float dist = length(oLightDir);
oLumin = 1 / (atten.y + atten.z * dist + atten.w * dist * dist);
oLumin = min(oLumin, 1.0);

oEyeDir = normalize(eyePosition - position.xyz);
oLightDir = normalize(oLightDir);

dist = length(oLightDir1);
oLumin1 = 1 / (atten.y + atten.z * dist + atten.w * dist * dist);
oLumin1 = min(oLumin1, 1.0);

oEyeDir = normalize(eyePosition - position.xyz);
oLightDir1 = normalize(oLightDir1);

}

void ETDynLightingNM_fp
(
float2 uv : TEXCOORD0,
float3 normal : TEXCOORD1,
float3 tangent : TEXCOORD2,
float3 binormal : TEXCOORD3,
float3 lightDir : TEXCOORD4,
float3 lightDir1 : TEXCOORD5,
float3 eyeDir : TEXCOORD6,
float lumin : TEXCOORD7,
float lumin1 : TEXCOORD8,

uniform sampler2D covMap1,
uniform sampler2D covMap2,
uniform sampler2D splat1,
uniform sampler2D splat2,
uniform sampler2D splat3,
uniform sampler2D splat4,
uniform sampler2D splat5,
uniform sampler2D splat6,

uniform float splatScaleX,
uniform float splatScaleZ,

uniform float4 lightDiffuse,
uniform float4 lightSpecular,
uniform float exponent,

out float4 oColor : COLOR
)
{
float3 cov1 = tex2D(covMap1, uv).rgb;
float3 cov2 = tex2D(covMap2, uv).rgb;
uv.x *= splatScaleX;
uv.y *= splatScaleZ;
float3 normModifier = tex2D(splat1, uv) * cov1.x
+ tex2D(splat2, uv) * cov1.y
+ tex2D(splat3, uv) * cov1.z
+ tex2D(splat4, uv) * cov2.x
+ tex2D(splat5, uv) * cov2.y
+ tex2D(splat6, uv) * cov2.z;

normModifier = normalize(expand(normModifier.xzy));

// Form a rotation matrix out of the vectors
tangent = normalize(tangent);
binormal = normalize(binormal);
normal = normalize(normal);
float3x3 rotation = float3x3(tangent, normal, binormal);

normModifier = mul(rotation, normModifier);
normModifier = normalize(normModifier);

lightDir = normalize(lightDir);
eyeDir = normalize(eyeDir);
float3 halfAngle = normalize(lightDir + eyeDir);

float NdotL = dot(lightDir, normModifier);
float NdotH = dot(halfAngle, normModifier);
float4 Lit = lit(NdotL, NdotH, exponent);

oColor = lumin * (lightDiffuse * Lit.y + lightSpecular * Lit.z * Lit.y);

lightDir1 = normalize(lightDir1);
eyeDir = normalize(eyeDir);
halfAngle = normalize(lightDir1 + eyeDir);

NdotL = dot(lightDir1, normModifier);
NdotH = dot(halfAngle, normModifier);
Lit = lit(NdotL, NdotH, exponent);


oColor+ = lumin * (lightDiffuse1 * Lit.y + lightSpecular1 * Lit.z * Lit.y);

//oColor = lightDiffuse * Lit.y + lightSpecular * Lit.z * Lit.y;
}


////////

After applying this script i loose all the texture

whethet i got problem in shader linking
Is my shader file correct

People3d

05-09-2008 13:57:31

Hi Man!
thx for all support you give me by this forum..
but i have a question...

i have modify the code following your instruction..
but the result was this...

[url=http://www.facebook.com/photo.php?pid=3]http://www.facebook.com/photo.php?pid=3 ... 1437256208

why?
..
i have made a little change..
i recalculate vertextangents when recalcultate vertex normal..

Code:

void Tile::updateTerrain(size_t startx, size_t startz, size_t endx, size_t endz)
{
// determine the area of this tile that needs to be updated
size_t fromX = std::max(mStartX, startx);
size_t fromZ = std::max(mStartZ, startz);
size_t toX = std::min(endx, mStartX+mOpt.tileSize-1);
size_t toZ = std::min(endz, mStartZ+mOpt.tileSize-1);

const VertexElement* posElem = mTerrain->vertexDeclaration->findElementBySemantic(VES_POSITION);
unsigned char* pBase = static_cast<unsigned char*>(mMainBuffer->lock(HardwareBuffer::HBL_NORMAL));

// update all necessary vertices
for (size_t j = fromZ; j <= toZ; ++j)
{
for (size_t i = fromX; i <= toX; ++i)
{
size_t tX = i - mStartX;
size_t tZ = j - mStartZ;
unsigned char* pBasePos = pBase + (tZ*mOpt.tileSize + tX) * mMainBuffer->getVertexSize();

Real height = mInfo.getOffset().y + mInfo.at(i, j) * mInfo.getScaling().y;
float* pPos;
posElem->baseVertexPointerToElement(pBasePos, &pPos);
pPos[1] = height;
}
}

mMainBuffer->unlock();

// update the extents of this terrain tile
size_t ex = mStartX + mOpt.tileSize;
size_t ez = mStartZ + mOpt.tileSize;
// find min and max heights
Real minHeight = mInfo.getOffset().y + mInfo.getScaling().y, maxHeight = mInfo.getOffset().y;
for (size_t j = mStartZ; j < ez; ++j)
{
for (size_t i = mStartX; i < ex; ++i)
{
Real height = mInfo.getOffset().y + mInfo.at(i, j)*mInfo.getScaling().y;
if (height < minHeight)
minHeight = height;
if (height > maxHeight)
maxHeight = height;
}
}
mBounds.setMinimumY(minHeight);
mBounds.setMaximumY(maxHeight);

mCenter = mBounds.getCenter();

mBoundingRadius = (mBounds.getMaximum() - mCenter).length();

// recalculate the distances at which to switch LOD
calculateMinLevelDist2();

// recalculate vertex normals, if necessary
if (mOpt.vertexNormals)
calculateVertexNormals();
//I Change this -> // recalculate vertex normals, if necessary
if (mOpt.vertexTangents)
calculateVertexTangents();
}




it' right?
thx 4 ur support

People3d

05-09-2008 13:59:04

Hi Man!
thx for all support you give me by this forum..
but i have a question...

i have modify the code following your instruction..
but the result was this...

[url=http://www.facebook.com/photo.php?pid=3]http://www.facebook.com/photo.php?pid=3 ... 1437256208

why?
..
i have made a little change..
i recalculate vertextangents when recalcultate vertex normal..

Code:

void Tile::updateTerrain(size_t startx, size_t startz, size_t endx, size_t endz)
{
// determine the area of this tile that needs to be updated
size_t fromX = std::max(mStartX, startx);
size_t fromZ = std::max(mStartZ, startz);
size_t toX = std::min(endx, mStartX+mOpt.tileSize-1);
size_t toZ = std::min(endz, mStartZ+mOpt.tileSize-1);

const VertexElement* posElem = mTerrain->vertexDeclaration->findElementBySemantic(VES_POSITION);
unsigned char* pBase = static_cast<unsigned char*>(mMainBuffer->lock(HardwareBuffer::HBL_NORMAL));

// update all necessary vertices
for (size_t j = fromZ; j <= toZ; ++j)
{
for (size_t i = fromX; i <= toX; ++i)
{
size_t tX = i - mStartX;
size_t tZ = j - mStartZ;
unsigned char* pBasePos = pBase + (tZ*mOpt.tileSize + tX) * mMainBuffer->getVertexSize();

Real height = mInfo.getOffset().y + mInfo.at(i, j) * mInfo.getScaling().y;
float* pPos;
posElem->baseVertexPointerToElement(pBasePos, &pPos);
pPos[1] = height;
}
}

mMainBuffer->unlock();

// update the extents of this terrain tile
size_t ex = mStartX + mOpt.tileSize;
size_t ez = mStartZ + mOpt.tileSize;
// find min and max heights
Real minHeight = mInfo.getOffset().y + mInfo.getScaling().y, maxHeight = mInfo.getOffset().y;
for (size_t j = mStartZ; j < ez; ++j)
{
for (size_t i = mStartX; i < ex; ++i)
{
Real height = mInfo.getOffset().y + mInfo.at(i, j)*mInfo.getScaling().y;
if (height < minHeight)
minHeight = height;
if (height > maxHeight)
maxHeight = height;
}
}
mBounds.setMinimumY(minHeight);
mBounds.setMaximumY(maxHeight);

mCenter = mBounds.getCenter();

mBoundingRadius = (mBounds.getMaximum() - mCenter).length();

// recalculate the distances at which to switch LOD
calculateMinLevelDist2();

// recalculate vertex normals, if necessary
if (mOpt.vertexNormals)
calculateVertexNormals();
//I Change this -> // recalculate vertex normals, if necessary
if (mOpt.vertexTangents)
calculateVertexTangents();
}




it' right?
thx 4 ur support

CABAListic

05-09-2008 15:20:15

Forget about the code change, just grab the latest ETM version, it's got those changes included.

SongOfTheWeave

06-09-2008 00:37:57

Forget about the code change, just grab the latest ETM version, it's got those changes included.

Roger that. CABAL is up earlier in the morning than I am :oops:

er, I guess that would be his afternoon.. blasted timezones!

SongOfTheWeave

06-09-2008 00:40:40

I ETTerrain

For dynamic light I had written tangent methods inET.

I changed shader files and normaps inserted.

as suggestions give in this forum.

I created single light in the scene it's working fine.

while creating another light. 2nd light doesn't effect the terrain.

First ie light0 is working fine.


check your ogre log. It will tell you if the shader is compiling correctly or if there are any errors on that side of things. It sounds like a shader isn't compiling. However, I'm not going to pour through the shaders looking for a mistake when your ogre log will tell you if there is an error and where.

Oceax

22-09-2008 03:23:39

Hi, thx for the shaders and instructions. I got the shaders working in my project but not perfectly. I use shader to do tangent calculation.

In DirectX i dont get any error. But light dosnt work.

In OpenGL i get this error: 19:53:28: Invalid Operation before loading program ETAmbient_VS.

And when i run the program with a POINT light placed on the map it looked like this

http://lanzer.mine.nu

looks good except.... thats a POINT light in the image but where ever i place the light on the map the part that is to the "left" of the light is just dark (ambient light).

Material file: http://lanzer.mine.nu/etterrain.txt

Any ideas what might be wrong? :S

CABAListic

22-09-2008 09:10:30

Perhaps you forgot to take an absolute value at some point in the shader? Remember that dot products of vectors can become negative which will render the affected parts black - your image looks just like that.

Oceax

22-09-2008 11:23:05

There was a problem with the normals... fixed it and everything looks great now in both OpenGL and DirectX. :)

Nauk

03-12-2008 12:38:43

Thanks again for sharing this SongOfTheWeave, I have tested it on several cards now and it runs fine, the only card I had a big problem with and only got distorted flickering on top of the splatting was the ATI X850, but after some trying a lot of different things I managed to fix it, so I wanted to share my find for others eventually having the same problem.

Uncommenting these lines in the ETDynLightingNM_vp from:

//oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
oBinormal = binormal;
//oBinormal = normalize(cross(tangent, normal));


to:

oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
oBinormal = binormal;
oBinormal = normalize(cross(tangent, normal));


made it work under DirectX9.

SongOfTheWeave

14-12-2008 00:29:45

Thanks again for sharing this SongOfTheWeave, I have tested it on several cards now and it runs fine, the only card I had a big problem with and only got distorted flickering on top of the splatting was the ATI X850, but after some trying a lot of different things I managed to fix it, so I wanted to share my find for others eventually having the same problem.

Uncommenting these lines in the ETDynLightingNM_vp from:

//oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
oBinormal = binormal;
//oBinormal = normalize(cross(tangent, normal));


to:

oTangent = -float3(abs(normal.y) + abs(normal.z), abs(normal.x), 0);
oBinormal = binormal;
oBinormal = normalize(cross(tangent, normal));


made it work under DirectX9.


Nauk, since you're using the lines to calculate tangents and binormals (which should be properly called bitangents) in the shaders you may safely comment or remove the lines and shader parameters that receive the tangents and bitangents from ETM/Ogre.

From the vertex program...

You may safely comment or remove the following lines:

oTangent = tangent;
oBinormal = binormal;


You may safely comment or remove the following parameters:

float3 tangent : TANGENT,
float3 binormal : BINORMAL,


----

The vertex program will still need to output the values it calculates for these and the fragment program will need to receive them.


Note: Using the latest ETM you may let ETM calculate the tangents for you, to do this, leave in the lines and parameters pertaining to tangents and comment out the line where the tangent is explicitly calculated in the shader.

Doing tangent calculation on the CPU (with ETM) is faster than calculating it in the shader. This is because ETM knows when the mesh is changed and only re-calculates the values for each vertex when the mesh is changed. Performing the calculation on the GPU means you are re-calculating it for every vertex, every frame whether or not the value has changed.

bmono100

29-12-2008 21:57:39

Hello,
First of all, thank you very much SoTW for the shaders and the code that you have posted on this particular forum.

There is one particular issue I've been having, and that's with the Normal Mapping shader, I keep running into a lighting issue where half the map is dark. It seems that when the light's direction vector has a positive x or z component the output color will be dark.

http://img504.imageshack.us/img504/4093 ... rorbn3.jpg

(The dark corner of the map is located at 0,0 - Actual coords in world space 0,300,0)

the code that creates the light on the particular terrain:


Ogre::Light* templight = mBaseScene->createLight("testLight");
templight->setType(Ogre::Light::LightTypes::LT_POINT);
templight->setDiffuseColour(.5f,.5f,0.50f);
templight->setSpecularColour(.1f,1.0f,0.5f);
templight->setVisible(true);
templight->setPosition(725,400,725);




With the particular shader, the normals for the terrain are being calculated correctly, as I altered the shader to output to see the normals and the values before and after the dot products for debugging purposes, and found that the problem lays with the dot product of the light direction and normal modifier.

Output of the "normModifier" as a color output on the actual terrain:
http://img397.imageshack.us/my.php?imag ... putjr9.jpg


Note: I'm using the default shader that SoTW has provided.


float3 normModifier = tex2D(splat1, uv) * cov1.x
+ tex2D(splat2, uv) * cov1.y
+ tex2D(splat3, uv) * cov1.z
+ tex2D(splat4, uv) * cov2.x
+ tex2D(splat5, uv) * cov2.y
+ tex2D(splat6, uv) * cov2.z;

normModifier = normalize(expand(normModifier.xzy));

// Form a rotation matrix out of the vectors
tangent = normalize(tangent);
binormal = normalize(binormal);
normal = normalize(normal);
float3x3 rotation = float3x3(tangent, normal, binormal);

normModifier = mul(rotation, normModifier);
normModifier = normalize(normModifier);

//Something seems to be missing at this point to make the normals and light
//vectors produce the correct result.

float NdotL = dot(lightDir, normModifier);
float NdotH = dot(halfAngle, normModifier);


The normals from the norm modifier are correct, and the values output from the rotation matrix seems correct, but when Dot the light direction and modifier it will produce a "0" value for the color when the light direction to the surface is a positive vector.

The Light Direction at 0,300,0 is: <725,100,725>

Light direction calculation from the vertex shader:

oLightDir = lightPosition.xyz - (position.xyz * lightPosition.w);



The only possible thing that could be causing this is that there is an error between the lighting direction and the normal dot product, like a step in the process is missing but not sure what line of code belongs in there.(I've been working at this for a few days now, and have not come up with a solution.)

Any help or ideas would be greatly appreciated. :)

If any more information is needed I will be more than happy to post as well, while I continue to work on this issue.


For reference etm 2.3.1 code for normals and tangents:


Vector3 TerrainInfo::getNormalAt(float x, float z) const
{
int flip = 1;
Vector3 here (x, getHeightAt(x, z), z);
Vector3 left (x-1, getHeightAt(x-1, z), z);
Vector3 down (x, getHeightAt(x, z+1), z+1);
if (left.x < 0.0)
{
flip *= -1;
left = Vector3(x+1, getHeightAt(x+1, z), z);
}
if (down.z >= mOffset.z + mScale.z*(mHeight-1))
{
flip *= -1;
down = Vector3(x, getHeightAt(x, z-1), z-1);
}
left -= here;
down -= here;

Vector3 norm = flip * left.crossProduct(down);
norm.normalise();

return norm;
}


/** Addition from SongOfTheWeave */
Vector3 TerrainInfo::getTangentAt(float x, float z) const
{
Ogre::Vector3 v3Return;
int flip = 1;
Vector3 here (x, getHeightAt(x, z), z);
Vector3 left (x - 1, getHeightAt(x - 1, z), z);
if (left.x < 0.0)
{
flip *= -1;
left = Vector3(x + 1, getHeightAt(x + 1, z), z);
}
left -= here;
v3Return = flip * left;
v3Return.normalise();
return v3Return;
}

bmono100

29-12-2008 22:44:52

Update:
Seems that the biggest problem with computer programs is the part that lies between the chair and the computer :).

I wasn't adding in the splatting maps to the lighting pass of the .material file.

SongOfTheWeave

31-12-2008 22:18:42

Update:
Seems that the biggest problem with computer programs is the part that lies between the chair and the computer :).

I wasn't adding in the splatting maps to the lighting pass of the .material file.


It's always the silliest mistakes that are the hardest top find.

Nauk

03-01-2009 13:35:09

@SongOfTheWeave: Thanks for the answer and the additional tips :)

plfiorini

04-01-2009 16:59:49

Thanks for the shaders. I'm using this stuff with Caelum but I have some problems.
Here's my material with normal mapping:

material AinurTerrainMaterialNormalMapping
{
technique
{
pass Ambient
{
vertex_program_ref Ainur/Programs/ETAmbient_VS
{
}
}

pass Lighting
{
scene_blend add
iteration once_per_light

vertex_program_ref Ainur/Programs/DynLightingNormalMapping_VS
{
}

fragment_program_ref Ainur/Programs/DynLightingNormalMapping_PS
{
param_named splatScaleX float 128
param_named splatScaleZ float 128
}

// Coverage maps, dynamically loaded by the engine
texture_unit
{
texture ETSplatting0
}
texture_unit
{
texture ETSplatting1
}
texture_unit
{
texture ETSplatting2
}

// Now adding the normal mapping textures
texture_unit
{
texture splatting_grass0_norm.png
}
texture_unit
{
texture splatting_grass1_norm.png
}
texture_unit
{
texture splatting_sand0_norm.png
}
texture_unit
{
texture splatting_rock0_norm.png
}
texture_unit
{
texture splatting_sand1_norm.png
}
texture_unit
{
texture splatting_rock1_norm.png
}
texture_unit
{
texture splatting_rock4_norm.png
}
texture_unit
{
texture splatting_rock2_norm.png
}
texture_unit
{
texture splatting_rock3_norm.png
}
}

// Primary splatting technique, requires PS 2.0
pass Splatting
{
scene_blend modulate

vertex_program_ref Ainur/Programs/LodMorph_VS
{
}

fragment_program_ref Ainur/Programs/Splat_PS
{
param_named splatScaleX float 128
param_named splatScaleZ float 128
}

// Coverage maps, dynamically loaded by the engine
texture_unit
{
texture ETSplatting0
}
texture_unit
{
texture ETSplatting1
}
texture_unit
{
texture ETSplatting2
}

// Splatting textures, dynamically loaded by the engine
texture_unit
{
texture Splatting0
}
texture_unit
{
texture Splatting1
}
texture_unit
{
texture Splatting2
}
texture_unit
{
texture Splatting3
}
texture_unit
{
texture Splatting4
}
texture_unit
{
texture Splatting5
}
texture_unit
{
texture Splatting6
}
texture_unit
{
texture Splatting7
}
texture_unit
{
texture Splatting8
}
}

// Colour map, dynamically loaded by the code
pass ColourMap
{
lighting off
scene_blend modulate
depth_bias 0.6 0.3

texture_unit
{
texture AinurTerrainColourMap
}
}

// Decal pass
pass decalsPass
{
lighting off
scene_blend alpha_blend
depth_bias 0.6 0.3

texture_unit
{
texture decalBase.png
}
}
}
}


I created the normal maps from the nVIDIA Photoshop plugin.

I have two problems:
1. In this screenshot http://img148.imageshack.us/img148/4946 ... ot1dx1.png you can see the PagedGeometry (which was patched to enable lighting) grass to be more bright thanks to the Caelum sun, but the terrain is too dark.
2. In this other screenshot http://img148.imageshack.us/img148/7753 ... ot2au5.png the lighting is weird and it becomes worse as you move the camera, I also put a video on youtube: http://www.youtube.com/watch?v=lZ1oWYNe1vk

What I'm doing wrong?

SongOfTheWeave

08-01-2009 01:49:26

Thanks for the shaders. I'm using this stuff with Caelum but I have some problems.
Here's my material with normal mapping:

material AinurTerrainMaterialNormalMapping
{
technique
{
pass Ambient
{
vertex_program_ref Ainur/Programs/ETAmbient_VS
{
}
}

pass Lighting
{
scene_blend add
iteration once_per_light

vertex_program_ref Ainur/Programs/DynLightingNormalMapping_VS
{
}

fragment_program_ref Ainur/Programs/DynLightingNormalMapping_PS
{
param_named splatScaleX float 128
param_named splatScaleZ float 128
}

// Coverage maps, dynamically loaded by the engine
texture_unit
{
texture ETSplatting0
}
texture_unit
{
texture ETSplatting1
}
texture_unit
{
texture ETSplatting2
}

// Now adding the normal mapping textures
texture_unit
{
texture splatting_grass0_norm.png
}
texture_unit
{
texture splatting_grass1_norm.png
}
texture_unit
{
texture splatting_sand0_norm.png
}
texture_unit
{
texture splatting_rock0_norm.png
}
texture_unit
{
texture splatting_sand1_norm.png
}
texture_unit
{
texture splatting_rock1_norm.png
}
texture_unit
{
texture splatting_rock4_norm.png
}
texture_unit
{
texture splatting_rock2_norm.png
}
texture_unit
{
texture splatting_rock3_norm.png
}
}

// Primary splatting technique, requires PS 2.0
pass Splatting
{
scene_blend modulate

vertex_program_ref Ainur/Programs/LodMorph_VS
{
}

fragment_program_ref Ainur/Programs/Splat_PS
{
param_named splatScaleX float 128
param_named splatScaleZ float 128
}

// Coverage maps, dynamically loaded by the engine
texture_unit
{
texture ETSplatting0
}
texture_unit
{
texture ETSplatting1
}
texture_unit
{
texture ETSplatting2
}

// Splatting textures, dynamically loaded by the engine
texture_unit
{
texture Splatting0
}
texture_unit
{
texture Splatting1
}
texture_unit
{
texture Splatting2
}
texture_unit
{
texture Splatting3
}
texture_unit
{
texture Splatting4
}
texture_unit
{
texture Splatting5
}
texture_unit
{
texture Splatting6
}
texture_unit
{
texture Splatting7
}
texture_unit
{
texture Splatting8
}
}

// Colour map, dynamically loaded by the code
pass ColourMap
{
lighting off
scene_blend modulate
depth_bias 0.6 0.3

texture_unit
{
texture AinurTerrainColourMap
}
}

// Decal pass
pass decalsPass
{
lighting off
scene_blend alpha_blend
depth_bias 0.6 0.3

texture_unit
{
texture decalBase.png
}
}
}
}


I created the normal maps from the nVIDIA Photoshop plugin.

I have two problems:
1. In this screenshot http://img148.imageshack.us/img148/4946 ... ot1dx1.png you can see the PagedGeometry (which was patched to enable lighting) grass to be more bright thanks to the Caelum sun, but the terrain is too dark.
2. In this other screenshot http://img148.imageshack.us/img148/7753 ... ot2au5.png the lighting is weird and it becomes worse as you move the camera, I also put a video on youtube: http://www.youtube.com/watch?v=lZ1oWYNe1vk

What I'm doing wrong?


That looks like an LOD issue but I'm guessing the main issue here is that if you want to use 9 splatting textures and 3 coverage maps you need to rewrite the splatting and the normal mapping shaders to handle 9 rather than six. My shaders handle six textures (The shaders themselves read the coverage maps and blend the individual textures accordingly). So if you want to use nine you'll have to add 4 more texture reads to the final colour calculations (and the normal map vector calculation). See the current shaders for the reference of how to do this for six textures, it is not hard to extend it to 9.

You will lose performance relative to the 6 texture shaders, but I'm not sure how much. Actually you'll lose compatibility with lower shader models too. I don't know what shader model you'll have to use to accept 12 texture units in one pass... CABAL do you know off hand? If you want greater compatibility you'll have to split the normal mapping and the splatting passes into two passes (so, four passes rather than two) or cut back to six textures. Or perhaps do 4 textures per coverage map and cut back to six textures. But that requires rewriting the shaders too.

plfiorini

08-01-2009 12:29:27


I have two problems:
1. In this screenshot http://img148.imageshack.us/img148/4946 ... ot1dx1.png you can see the PagedGeometry (which was patched to enable lighting) grass to be more bright thanks to the Caelum sun, but the terrain is too dark.
2. In this other screenshot http://img148.imageshack.us/img148/7753 ... ot2au5.png the lighting is weird and it becomes worse as you move the camera, I also put a video on youtube: http://www.youtube.com/watch?v=lZ1oWYNe1vk

What I'm doing wrong?


That looks like an LOD issue but I'm guessing the main issue here is that if you want to use 9 splatting textures and 3 coverage maps you need to rewrite the splatting and the normal mapping shaders to handle 9 rather than six. My shaders handle six textures (The shaders themselves read the coverage maps and blend the individual textures accordingly). So if you want to use nine you'll have to add 4 more texture reads to the final colour calculations (and the normal map vector calculation). See the current shaders for the reference of how to do this for six textures, it is not hard to extend it to 9.

You will lose performance relative to the 6 texture shaders, but I'm not sure how much. Actually you'll lose compatibility with lower shader models too. I don't know what shader model you'll have to use to accept 12 texture units in one pass... CABAL do you know off hand? If you want greater compatibility you'll have to split the normal mapping and the splatting passes into two passes (so, four passes rather than two) or cut back to six textures. Or perhaps do 4 textures per coverage map and cut back to six textures. But that requires rewriting the shaders too.


What a stupid newbie I am :)
In the meanwhile I started getting a clue about shaders and I can understand the problem (I even think to be able to fix it, in case I will post the modified shader). The fragment program with 12 textures in one pass should work with ps_2 profile which is supported by every D3D9 card out there. Anyway I am not interested in < D3D9.

Thank you very much.

Progger

10-01-2009 22:09:09

Thank you for sharing SongOfTheWeave :wink:
I'm new to shader programming and I have some issues with dynamic lighting though.

Here little code how many lights I positioned (only one point light):
Ogre::Light *pLight = m_pSceneMgr->createLight("p_light");
pLight->setType(Ogre::Light::LT_POINT);
pLight->setDiffuseColour(Ogre::ColourValue(1.0f, 1.0f, 1.0f));
pLight->setPosition(500.0f, 200.0f, 500.0f);

Ogre::Entity* pEnt = m_pSceneMgr->createEntity("Ninja", "ninja.mesh");
Ogre::SceneNode* pNode = m_pSceneMgr->getRootSceneNode()->createChildSceneNode("Ninja");
pNode->setPosition(Ogre::Vector3(500.0f, 200.0f, 500.0f));
pNode->attachObject(pEnt);

As you can see the point light is positioned at the feets of the ninja. Though, it affects other areas of the terrain.
Here some screenshots:





As you can see the normal map provides strange results and the point light affects different areas based on camera position/orientation.
At some camera settings the light turns itself even completly off. But the main problem that I see here is the low FPS although this application is running in release configuration :(

SongOfTheWeave

11-01-2009 00:48:41

Thank you for sharing SongOfTheWeave :wink:
I'm new to shader programming and I have some issues with dynamic lighting though.

Here little code how many lights I positioned (only one point light):
Ogre::Light *pLight = m_pSceneMgr->createLight("p_light");
pLight->setType(Ogre::Light::LT_POINT);
pLight->setDiffuseColour(Ogre::ColourValue(1.0f, 1.0f, 1.0f));
pLight->setPosition(500.0f, 200.0f, 500.0f);

Ogre::Entity* pEnt = m_pSceneMgr->createEntity("Ninja", "ninja.mesh");
Ogre::SceneNode* pNode = m_pSceneMgr->getRootSceneNode()->createChildSceneNode("Ninja");
pNode->setPosition(Ogre::Vector3(500.0f, 200.0f, 500.0f));
pNode->attachObject(pEnt);

As you can see the point light is positioned at the feets of the ninja. Though, it affects other areas of the terrain.
Here some screenshots:

--Images removed for brevity--

As you can see the normal map provides strange results and the point light affects different areas based on camera position/orientation.
At some camera settings the light turns itself even completly off. But the main problem that I see here is the low FPS although this application is running in release configuration :(


A few questions so I can diagnose your problem:

  1. Are you using the normal maps I supplied in the OP or other normal maps?[/*:m]
  2. Do you have any shadow technique turned on? If so, provide some details about it.[/*:m]
  3. It was hard to tell from the pictures, but is the light only lighting in say, the positive x and z directions? Is it a problem like that? Where it only lights in certain directions?[/*:m]
  4. Is your scene manager's ambient colour set to 0, 0, 0, 0? (That might be part of what's causing the extremely contrasty image you're getting).[/*:m]
  5. Do you see sharp lines where the light ends or does it gradually end?[/*:m]
  6. Have you modified the shaders at all?[/*:m][/list:u]

Progger

11-01-2009 15:05:16

Thank you for reply I'll try to answer the quetions:

Are you using the normal maps I supplied in the OP or other normal maps?
Yes, I'm using the normal maps you supplied in the first post.

Do you have any shadow technique turned on? If so, provide some details about it.
No shadows are used (shadow technique = none)

It was hard to tell from the pictures, but is the light only lighting in say, the positive x and z directions? Is it a problem like that? Where it only lights in certain directions?
Here is a video that should clarify the problem. I switch here to stencil addive shadow technique.
Two problems emerge: 1. the last frame is not cleared. I had the same problem with a game and I think this causes my grafic card. But I should analyse this problem later.
2. The scene turns darker and the hills of the terrain looks more darker than the other terrain areas.
Unfortunately, I couldn't catch the moments where the light alters its direction (point light?) like shown in the middle screenshot above, because all the time I start to record the scene (I'm using fraps) the light illuminates only the "initial" terrain areas like shown in the first screenshot.
The secod time I switch to texture additive shadows and get some "light points".

Is your scene manager's ambient colour set to 0, 0, 0, 0? (That might be part of what's causing the extremely contrasty image you're getting).
You mean ambient light? It is "0.1 0.1 0.1". But even if I try with other values like "0.5 0.5 0.5" the image is still such contrasty.

Do you see sharp lines where the light ends or does it gradually end?
As shown in the pictures above the light ends gradually.

Have you modified the shaders at all?
Since I don't know how these shaders work I haven't modified the shaders but copied & pasted them from the thread.
I found interesting stuff where I could learn shader programming, so I hope to solve these issues with the gained knowledge ;)

cu

SongOfTheWeave

27-01-2009 10:26:37

What else is in your terrain material?

Those hexagon patched you see in the video are LoD artifacts due to some pass in the terrain shader not compensating for the LoD technique that ETM uses. I know that my shaders do compensate for this and the splatting ones provided with ETM do so I'm not sure what's causing it.

I saw you switching shadow modes in the video, ogre default texture shadow modes won't work with ETM, you'll have to write your own shaders.

I'm not sure why your problem is happening... it's possible that it is something unrelated. Your screen redraw issue where the ninja smears across the view makes me wonder if the problem isn't due to some other problem outside of these shaders.

Oh! Check your ogre log for errors and warnings!

Progger

01-02-2009 19:26:25

Hi, I've experienced a lot since then and know now how to simulate the basic light with shaders. But I get always the same problem. The log is clear (no errors).
The strange thing about it is that if I provide a some other object like a simple plane with my self written shader code, the terrain looks better (nice normal mapping effects). But the point light in my scene spreads its light only on its relative x-axis. And at some camera diretions the terrain is simply black.

bunny2015

08-02-2009 01:48:10

Hi, I've experienced a lot since then and know now how to simulate the basic light with shaders. But I get always the same problem. The log is clear (no errors).
The strange thing about it is that if I provide a some other object like a simple plane with my self written shader code, the terrain looks better (nice normal mapping effects). But the point light in my scene spreads its light only on its relative x-axis. And at some camera diretions the terrain is simply black.

Jesus!
I meet the same thing, It afflict me a whole night!
But this strange thing is simple. We forgot to set ETM to calculate normal and tangent!
The same reason in old post someone say don't support direct3d rendersystem.
Maybe have other reason, but I think this is Frequently.

SongOfTheWeave

08-02-2009 03:10:10

Hi, I've experienced a lot since then and know now how to simulate the basic light with shaders. But I get always the same problem. The log is clear (no errors).
The strange thing about it is that if I provide a some other object like a simple plane with my self written shader code, the terrain looks better (nice normal mapping effects). But the point light in my scene spreads its light only on its relative x-axis. And at some camera diretions the terrain is simply black.

Jesus!
I meet the same thing, It afflict me a whole night!
But this strange thing is simple. We forgot to set ETM to calculate normal and tangent!
The same reason in old post someone say don't support direct3d rendersystem.
Maybe have other reason, but I think this is Frequently.


OH! Good insight bunny, that's the problem.

Adding a note in the OP to remind people of this.

Progger

08-02-2009 13:25:54

Hi, I got it now! Thank you very much ;)
I knew that ETL was intended to calculate normals and tangents like mentioned in the shaders. But I thought it was the default situation. Looking closer to the createTerrain method helped me out.

Now I was focusing on the performance and i was a little disappointed :(
Starting point:
  1. video card: NVIDIA GeForce Go 7300
    release configuration
    the same initial position and orientation
    highly deformed terrain with 6 splatting textures on it
    I'm using nearly the same code like in the demo (Terrain: 129, 129)[/list:u]
    Results: average FPS over one minute
    1. No dynamic lighting: approx. 59
      dynamic lighting with normal mapping: approx. 24[/list:u]

      I don't think that this is normal. Could you please give me some advice how to "fix" this?

SongOfTheWeave

09-02-2009 05:46:27

Hi, I got it now! Thank you very much ;)
I knew that ETL was intended to calculate normals and tangents like mentioned in the shaders. But I thought it was the default situation. Looking closer to the createTerrain method helped me out.

Now I was focusing on the performance and i was a little disappointed :(
Starting point:
  1. video card: NVIDIA GeForce Go 7300
    release configuration
    the same initial position and orientation
    highly deformed terrain with 6 splatting textures on it
    I'm using nearly the same code like in the demo (Terrain: 129, 129)[/list:u]
    Results: average FPS over one minute
    1. No dynamic lighting: approx. 59
      dynamic lighting with normal mapping: approx. 24[/list:u]

      I don't think that this is normal. Could you please give me some advice how to "fix" this?


59 fps with no lighting is pretty bad. Unless that's due to vsync I'm surprised you got as many as 24 with dynamic lighting and normal mapping.

Lighting is expensive. You could improve your performance by not doing normal mapping, having fewer lights. You could also modify the shaders in the way i suggest in the OP but haven't done yet.

Also, I don't know how a geforce go 7300 should perform.

bunny2015

10-02-2009 04:03:47

Hello,
I have a new problem:
[attachment=1]err1.jpg[/attachment]
Some square have not to be render in normalmap render pass.

[attachment=0]err2.jpg[/attachment]
The splatting pass work fine!

shader: SongOfTheWeave
program:
ETM demo,
scene: ETM + one point light
platform: windows xp sp2 + vs2008 + ogre 1.6.0 + d3drender

I have no idea.
Someone know it?
Thanks.

SongOfTheWeave

10-02-2009 17:30:10

You need to set your light range longer than the attenuation range. Or rather, you need to set your attenuation so that it gets dim enough by the time you hit the light "range" that you don't see a sharp cutoff.

I'm not sure why your splatting texture is only being applied to one of the patches in your second screen shot, but I suspect that's something you did yourself.

btw, what are you doing to get the orange wireframe terrain selection thing in your screenshots? Is it just a manual object you're creating overtop the terrain?

Progger

10-02-2009 18:21:19

...

59 fps with no lighting is pretty bad. Unless that's due to vsync I'm surprised you got as many as 24 with dynamic lighting and normal mapping.

Lighting is expensive. You could improve your performance by not doing normal mapping, having fewer lights. You could also modify the shaders in the way i suggest in the OP but haven't done yet.

Also, I don't know how a geforce go 7300 should perform.


Yes, it's due to vsync. Otherwise I get approx. 50 FPS when I try to capture all the terrain into the viewport (no dyn lighting). Looking away from it get me approx 350 FPS. It's quite interesting how my video card handles the terrain :lol:
Nonetheless, thanks for your advice, I'll try it out ;)

bunny2015

11-02-2009 02:11:02

You need to set your light range longer than the attenuation range. Or rather, you need to set your attenuation so that it gets dim enough by the time you hit the light "range" that you don't see a sharp cutoff.

I'm not sure why your splatting texture is only being applied to one of the patches in your second screen shot, but I suspect that's something you did yourself.

btw, what are you doing to get the orange wireframe terrain selection thing in your screenshots? Is it just a manual object you're creating overtop the terrain?

Oh, I am sorry. I have not describe it clear.
The screen shot is to be captured at the time when I use NVIDIA PerfHUD 6 to debug the program.
So, in my second screen shot, the splatting texture will applied to all of the patches, It's ok. The problem is first screenshot, Some patches had not to be render! In normal map pass, some where had not any vertexes to be commit to graphic card!
So, some patches we look is black.
But in splatting pass, all patches to be render, no lost.
I can't find a way to explain it, some patches lost in normalmap pass, why?

bunny2015

13-02-2009 02:53:04

You need to set your light range longer than the attenuation range. Or rather, you need to set your attenuation so that it gets dim enough by the time you hit the light "range" that you don't see a sharp cutoff.
......

Yes, you are right. Ogre will set renderable's lightlist to empty when the renderable out of range. Thanks a lot. But why do you not support range in your shader? In default lighting, the range is effective, it always cutoff the light where out of range.

haibo19981984

26-09-2009 09:32:46

At first,thanks for SongOfTheWeave.
I'm trying to use etm2.3.1's sample for testing ETM's lighting.
this is VS's interface:
[attachment=2]etm2.jpg[/attachment]
this is resource's interface:
[attachment=1]etm1.jpg[/attachment]
this is my material "ETTerrain.material":

material ETTerrainMaterial
{
technique
{
pass Ambient
{
vertex_program_ref ETAmbient_VS
{
}
}

pass Lighting
{
scene_blend add
iteration once_per_light

vertex_program_ref ET/Programs/VSDynLightingNM
{
}

fragment_program_ref ET/Programs/PSDynLightingNM
{
}
texture_unit
{
// first coverage map, dynamically managed
texture ETSplatting0
}
texture_unit
{
// second coverage map, dynamically managed
texture ETSplatting1
}

// splatting textures
texture_unit
{
texture splatting0_norm.png
}
texture_unit
{
texture splatting1_norm.png
}
texture_unit
{
texture splatting2_norm.png
}
texture_unit
{
texture splatting3_norm.png
}
texture_unit
{
texture splatting4_norm.png
}
texture_unit
{
texture splatting5_norm.png
}
}
pass Splatting
{
scene_blend modulate

vertex_program_ref ET/Programs/VSLodMorph2
{
}

fragment_program_ref ET/Programs/PSSplat2
{
param_named splatScaleX float 20
param_named splatScaleZ float 20
}
texture_unit
{
// first coverage map, dynamically managed
texture ETSplatting0
}
texture_unit
{
// second coverage map, dynamically managed
texture ETSplatting1
}

// splatting textures
texture_unit
{
texture splatting0.png
}
texture_unit
{
texture splatting1.png
}
texture_unit
{
texture splatting2.png
}
texture_unit
{
texture splatting3.png
}
texture_unit
{
texture splatting4.png
}
texture_unit
{
texture splatting5.png
}
}
}
}

the script ETDynLighting.cg is just you post.
I just add the script .program you post to ETShader.program.
the other resource belong to etm2.3.1.
this is my shot:
[attachment=0]etm3.jpg[/attachment]
I just add some code to etm2.3.1's sample in "createScene()":

mSceneMgr->setAmbientLight(ColourValue(0.5, 0.5, 0.5));
Entity *ent2 = mSceneMgr->createEntity("Robot", "robot.mesh");
ent2->setCastShadows(true);
SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode("Node2", Vector3(

250, 150, 900 ));
node2->attachObject( ent2 );
node2->scale(0.5, 0.5, 0.5);

Light* lit = mSceneMgr->createLight("lit");
lit->setType(Light::LT_POINT);
lit->setDiffuseColour(1.0, 0.0, 0.0);
lit->setSpecularColour(0.0, 1.0, 0.0);
lit->setVisible(true);
lit->setPosition(250,300,950);

Light* lit1 = mSceneMgr->createLight("lit1");
lit1->setType(Light::LT_POINT);
lit1->setDiffuseColour(0.0, 1.0, 0.0);
lit1->setSpecularColour(0.0, 0.0, 1.0);
lit1->setVisible(true);
lit1->setPosition(20,300,10);

It seems that the ambient light can affect the ETM's terrain.
But the point light can not.
Anybody can solve the problem?
I use ogre1.62 and my GPU is NVIDIA GeForce 9500 GT.
And I check the ogre's log.It don't list the error of ETDynLighting.cg.

lonwolf

26-09-2009 18:09:50

i have the same problem as you. i placed a lot of lights and they don't seem to affect it (not using normal maps, only the fragment and vertex lighting programs). i reached a dead-end. All i want is to have the day/night transition to have an effect on the terrain.

[edit] finally figured it out. forgot to add the calculate tangent vectors and normals :lol: happens :)
If you find your terrain not working properly, take a look at the createTerrain params and set the last 2 to true :D

haibo19981984

27-09-2009 09:58:42

Thanks for lonwolf.
The problem is sovled finally. :mrgreen:

pritamsingh98

03-12-2009 23:09:44

wow ...... nice one

Kreso

07-05-2010 10:57:28

someone please delete this user, he's been spamming the forum frequently >:(