One possibility might be, that the normal map was created based on the diffuse texture. I think the tools and plug ins, that create normal maps from 2D textures use the brightness values of the image. Often darker parts of the texture are lower, but in this case the spaces between the bricks are very bright, almost as bright as the bricks. So I would recommend - before creating the normal map - to make a greyscale copy of the texture and manually darken the parts between the bricks, to make sure, that the normal map has some depth (like a bumpmap).
I would also use the alpha channel to control the specularity. Bricks are usually not very shiny ...

OK cool. Found a tutorial on doing that at the AU site and looks much better now. Thank you

OK got that problem fixed. I still noticed that it dont apply the effects of being raised. The textures I purchased did come with bumps. Is there a way in idiot terms to do these ?

Quote:

---

I still noticed that it dont apply the effects of being raised.

---

Well, I did some tests now, and I can confirm this, even when I create the normal map (or should I call it a DOT3 bump map) based on a greyscale texture, that has a lot of contrast (I use a little ATI tool for this). The 3D effect is only visible in areas with high specularity.
Maybe for this shader the normal maps are better created with a different tool or procedure (maybe with 3D models)? I will try that.
Or is there a line in the .fx file, that controls the strength of the 3D effect?


There are some other things, that I noticed ...

1) For outdoor stuff it would be great if the shader could react to changes of sun_color. At the moment I would have to adjust the material, but this works fine (like with predefined materials btw., so it is consistent).

2) Objects with the NM material seem to be immune for shadows. I just tested with stencil shadows. Shadows are not rendered on the surface of the normalmapped models and the models also do not cast shadows.

3) The shading on the faces - when they receive sun_light is not really realistic. There is a visible fall-off (on large faces). The sun_light however should not produce such a fall-off even if it looks nice sometimes

All my tests were done in a model-based level without blocks and lightmapping.

Anyway it´s a really nice and very useful shader!

1) sun_color isn't passed to the shader, but you can easily amke it so that the material values are set to the sun_color every frame. Just open the NM.wdl, go to the mat_NM_event() and add vec_set(mtl.specular_blue, sun_color);

2) Stencil shaddows worked just fine for me...

3) I thought I left out the attenuation on sunlight. I'll do some testing. Also, the large faces your using for testing, are the just faces, or actaully shapes. The vertice normal are interpolated, so the edges might think their facing away from the sun...

4) Static lighting only works when their are blocks to read the lightmaps from. Only stencil shadows will work. The shadows are not controlled by the shader at all. stencil shadows also pass through objects, so use them carefully...

Thank you for this very nice contribution!
After playing around with this shader, I noticed that the c_trace slows the entity rendering speed down a lot.
I haven´t a clue about shaders, but I remembered a ffp-bumpmapping effekt, wich was everytime as bright as the ground below it, or at least it seemed so.
I took a closer look at it and found vecLight.
I replaced your mtlSkill1 with vecLight and this looks all right in my testlevel (ok it´s a bit brighter then using the trace). So my question is, what´s wrong with vecLight?

Another thing wich interests me is c_scan cause in the manual it sais:

Quote:

---

c_scan (VECTOR* pos, ANGLE* dir, VECTOR* sector, var mode);
[...]

The following mode values can be set:
[...]
SCAN_LIGHTS Scans for static lights.
[...]

Modifies:
you Pointer to the closest detected entity.
result Distance to the closest detected object.
target Position of the closest detected object.
bounce Angle of the closest detected level camera position.
tex_color Color of the closest detected static light.

[...]

---

Are these static lights those placed in WED?

Thanks,
Slin

Sorry for question,

but is there anyway using this shader on normal map blocks?

Because I like this shader and it would be great if there is anyway to use them on blocks.

Greetings
TSGames

Is there a way to adjust this fog. I do not have it set in 3dgs period

Hi!
You might simply uncomment these lines

fog_color = 1;
camera.fog_start = 5;
camera.fog_end = 800;

in the effect_startup function of the NM wdl. They were probably for testing.

@ Guitar: I found out, what´s causing the problem with stencil shadows. It has nothing to do with the shader. The problem is, as soon as there´s a skin with alpha channel, the engine "thinks" it´s transparent and refuses to render stencil shadows. Well I need the alpha channel for specularity control. If I use a 24bit texture, the stencil shadows work, but I have too much specularity.
I tried
my.transparent = off;
and my.flare = off;
but it didn´t help. I think someone here in the forum has mentioned this problem sometime ago ...

@Slin: The c_scan() method only returns the color of the lightmap below the entity, not the lights position. I'm doing the same thing with c_trace(). I am using this method to light the model with static lights (as you can see). When I was working on the shader, I was getting horribly incorrect results with vecLight, therefore I wrote my own method for doing static lighting. I'll mess with it some more.

@TSGames: It is possible, but not realistic. Shaders on WED blocks are TOO slow. This is why many developers are now creating thier levels with models.

@foodstamp: Robotronic explained the problem. This was for testing, and I had forgotten to remove it. I'll remove it tonight.

@Robotronic: Adjusting specularity by the alpha channel, should be the alpha channel of the normal map, not the diffuse map. I used stencil shadows in my testing, and had no problems, but I also was using a 24 bit tga for my diffuse map, therefore no alpha channel there. Only in my normal map. I may be wrong here, so please correct my if I am.

@All: As always, the are some bugs that needed to be fixed. I'm going to update the code tonight, and then post it when it's working again. Thank you all for your comments, help, and kind gratitude...