Shiny normalmap shader shouldn't be shiny

Hello,

I'm continuing on my quest to get a shader that has both normalmap and a lightmap (and I'm trying to learn how to use oFusion while I'm at it). This is meant to go on a house that will use the lightmap for ambient occlusion shading, and the normalmap for the cracked paint on the old wood siding.

Here's what I've got so far:



This shader is basically the shader from the normalmapping tutorial, the one with the torus. However, I added the lightmap to it by adding a texture unit to the base_pass.

(Note that, according to Lioric, I should be instead adding the lightmap to the decal_pass, and that sounds right to me. However, as I mentioned before, when I try putting it in the decal pass, it turns the whole thing black. Any suggestions for a fix for the blackness would be appreciated.)

The lightmap has its own UVs, as do the normalmap and the diffuse map. The normalmap UVs cause the map to repeat at a very small scale (because the cracks in the paint are very small).

The big problem I see at the moment is that the whole thing is very shiny. You can see the highlight to the left of the oFusion logo - is there any way to get rid of this?

One thing about that highlight: it seems to change size with the scale of the normalmap UVs. Like I said, the normalmap is scaled to make the texture very small relative to the surface, and this also makes the highlight small.

I saw elsewhere in this forum where Lioric said that shaders are not general-purpose, and I got the impression that they need to be tailored to the geometry. Could that be why there's this highlight? Like, the shader was meant for use on the torus, so putting it on a rectilinear object is just wrong?

If that's the case, any suggestions how I might fix it?

One other weird thing is that the house seems lit from all sides. That is, there's only one actual light in the scene, but if I turn to look at what should be the dark side of the house, I see the same highlight. It's as if there's a flashlight attached to the camera.

As always, any help is greatly appreciated. I'm flailing around in the darkness here

That multipass shader is used when you want to use with dynamic additive shadows in your scene

As you are using LMs as the shadows, search this forum for the "Monster shader", it is a fast single pass normal mapping shader with excellent results

Hi Lioric,

I will be also adding dynamic additive shadows. My plan was to use the lightmap for ambient occlusion only, and then use a dynamic light for sunlight.

Anyway, the problem I was most hoping to get fixed was the shininess of the surface. Probably like most artists trying to get the hang of Ogre and oFusion shaders, I'm coming at it from a background in Max and Maya, and I'm used to having a value I can crank to make a surface more or less shiny. It seems different when using this shader.

Again, this is the shader from the torus normalmap tutorial. I just added a lightmap to it.

This is what it looks like in action:

http://www.youtube.com/watch?v=7n5IjUmLpTA

It looks more like tin foil than painted wood

Does it appear shiny because of the difference between the normals of the rounded torus and the rectilinear house?

This shader precalculates a shininnes value for the specular exponent, but this is to mantain ps1 compatibility

If you dont need ps_1 compatibility (and support from ps_2), then you can add a shininnes parameter to the pixel shader to control it in the parameter editor

Hi Lioric,

If you look at the video:

http://www.youtube.com/watch?v=7n5IjUmLpTA

You see a house with a bright, round spot on it. Almost a highlight, as if there's a flashlight attached to the camera, and as if the house is made of reflective metal surface. There shouldn't be a highlight, and it shouldn't look as if the light is coming from the camera. I have no idea why it's doing this. I've played with every value I can in the shader, and I see no change.

Can you suggest anything specific I could do to fix this specific problem? I'd really appreciate it.

I think its the kind of shader it is. The tutorial shiny bump map shader works best on closed convex curved surfaces. The lighting doesn't really work well at all on anything flat.

Monster is the only readily avaliable bump map shader already setup for ofusion and will work on flat surfaces like walls on buildings.

Thanks for the reply Evak,

The tutorial shiny bump map shader works best on closed convex curved surfaces.

I wondered if that might be the case. Is that something to do with the normals? I've read something in the forum about oFusion shaders an it sounded to me like normals are somehow stored in one of the UV mapping channels. That sound right? I used up several mapping channels for this shader on this house, so I'm wondering if that might affect the way the shader works.

Basically, while it makes sense that the tutorial shader works best for that torus, and while the Monster shader sounds like a viable option, I remain curious as to how to make the tutorial shader do... what I want it to do . Is there anything I can tweak to make the tutorial shader work on the house? (I hate not knowing how things work.)

Again, the Monster shaders do sound promising, and I'll check them out.

In case it helps someone else, my attempt to find the Monster shaders, and to figure out how to get them into oFusion led me to this wiki:

http://www.ogre3d.org/wiki/index.php/The_Monster

Which had a broken rapidshare link (http://rapidshare.de/files/24150015/ofusion.zip.html).

I emailed Guilderstein about it, and he sent me this link:

http://rapidshare.com/files/44154590/Ofusion.zip.html

Which has Monster shaders and instructions on how to get them in oFusion. I was able to download that file, but I haven't tried it out yet.

(Edit: looks like Guilderstein updated this thread http://www.ogre3d.org/phpBB2/viewtopic.php?t=22191&start=50 with a link to the same download as he sent me.)

BTW, I've had some problems recently with defines not working 100% in ofusion. So if any of the defines are set to 0 they may spit out a compile error but still work ok.

I havent posted a bug report yet, but its something I have been meaning to look into some more when I have the time.

SHaders are a complicated beast for non programming artists. I need a lot of assistance from one of our coders when I want to convert a shader I created in a tool, so its compatible with Ogre.

From what I understand Ogre does use a texcoord to stream tangents, and if you look at Liorics shiny bump map coordinates, its recommended to calculate the binormals inside the shader itself.

My understanding of shaders is a bit vague to be much help at this point

I'm using ShaderFX for 3dsmax to design my shaders, and then get some help from one of the coders in my team to make them compatible with ogre and ofusion.

Thanks again for the help, Evak.

One more question for you: do you ever find that the bumps in normal maps sometimes get inverted? Such that, in the case of the brick wall normal map, (from the tutorial) the mortar seems to be sticking out instead of the bricks.

If so, is there a fix?

I seem to recall that Nvidia and Ati have their Green Y axes pixels in normal maps inverted. So the depth of the bump mapping would be flipped if you had a normal map for the wrong hardware.

This was a while ago, I'm not sure if the problem still persists, or if there is an easy workaround. I noticed that the tools I use to make the normal maps allow you to flip the Y.

Evak,

I'm sorry, I didn't explain that well. The problem I'm seeing is that the normal mapping seems inverted on only some sides of a given object. It'll work OK on others.

Like if I make a sphere in Max with default UV coordinates, and then put this Monster shader on it, the bricks look OK on one side, but inverted on the other. This is with 3 omnis directly over the sphere.

I think normalmaps are working on my machine in general. I was wondering about that, but as a test, I made a standard Max material with a normal map bump map, and then assigned that to an object. No matter which side I rendered it from, it looked OK.

Also, normal mapping in games looks fine.

I've also used normalmaps in the Unreal Engine 3 on this machine, and they seemed to work fine.

BTW, if you want to play with a seriously easy-to-use game art tool, try UE3. You can get it with the game Roboblitz, which is available via Steam. Just import the normal map, hook it to a material, then slap the material onto your mesh. Sigh... so easy. I guess that's why it costs a quarter-mil (among other reasons).

ShaderFX for max is quite similar to the unreal 3 shader editor, it costs $250 though, and only saves in .FX format. It's a really nice tool

http://www.lumonix.net/shaderfx.html

it renders the shader in realtime in your max viewport and now supports glow effects, subsurface scattering and what have you. a normal map shader like what your looking for only requires 3 nodes with the standard material, 4 if you want to add a specular map, and vertex color shader effects can be painted in 3dsmax in realtime

ShaderFX looks pretty great. And you're able to get those shaders working in Ogre?

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

Back to the problem I'm seeing, IF ANYONE can suggest a fix for what I'm seeing:



wherein, as you can see, even with all the lights overhead, the bricks on the box seem to be illuminated from below (which sometimes reads as if the mortar is sticking out rather than the bricks), I'd really, really appreciate it.

The light seems to be correct (comming from the upper part), the specular you experience in the bottom of the bricks is mostly because of the shader, have you added the shinnines parameter to the pixel shader?

I can add the parameter to the shader and post it, if your prefer

Hi Lioric,

I hadn't added the shininess parameter to the shader. That would affect the direction from which the light seems to be hitting the surface?

To make sure we're looking at the same thing, I've uploaded another image:



The spot indicated is the most glaring error. The bricks there look very much like they're lit from below. However, the only lights in the scene are directly above the box.

Also, the other sides of the box look OK relative to this one, they appear to be lit from above.

I think the normal map has the Y pixels the created the opposite direction to what your video card requires.

If you download the Nvidia DDS normal map filter for photoshop, or the ATI equivalent and flip Y, then the lighting direction will be flipped and be correct in your scene.

I had a quick look at the nvidia photoshop plugin and you can flip the normal map direction on the axis of your choice.

Positive or Negative Y
When using Tangent Space normal maps, the most common difference in formats is the direction that the green channel is lit. Some programs light the green channel from the left (postive Y) and others light the green channel from the right (negative Y). Some programs give you the option to choose positive or negative Y. If your normal map isn't being lit correctly, the first thing that you should try is to flip the green channel. Just open the normal map in Photoshop, select the green channel, and choose "Invert." That will give you the same result as if you had rendered the normal map in the other format.

Hello.

You may find this silly but It happened to me.

I had weird illumination problems with shaders when I tried the normal mapping.

I posted with images etc...

I received many tipe of possible errors, but it was so silly that no one told me to check it, and it was the problem.

Have you check the "generate tangent vectors" objet property?
If not this could be the prob.

Thanks for the replies, guys.

Evak: I see what you mean (and thanks for looking into that), but if what you describe were the case, wouldn't the whole shader be inverted, all over the cube? It's rendering correctly on at least one side.

Maybe I'll post a video when I get a chance.

Paulov: That's a good suggestion, and I do keep forgetting that "generate tangent vectors" check box. However, in this case I remembered to check it, and it didn't yield a fix.

Spence,

Did you get this to work? If not, I can take a looksee..

Eric

Hey Eric,

I'll certainly take any help if you're offering! I'll send you the Max file, textures, and Monster shader. Let me know if you need anything else.

Here's a video of the shader problem:

http://www.youtube.com/watch?v=2SRM9n2s0jo

I start off from a distance to show where the lights are: directly above. Then I then zoom in to show the side of the box that looks inverted to me, as if the bricks are lit from below (or as if the mortar is sticking out and the bricks are indented - it does a kind of optical-illusion "pop" between the two when I look at it). Then I turn the box, and you can see that each side is lit a little differently. One side, at minute 00:15, actually looks perfect, like it's lit from above.

So, yeah... that's the problem.

Evak, I still want to look into your suggestion of flipping the Y, but the question still nags at me: if that were the case, wouldn't the bricks be inverted on all sides?

Following up on this problem, because I never did figure it out...

To recap, this is the problem I was seeing:



Even though lights are above the box, the highlights on the brick normal map make the bricks appear to be lit from below (but only on some sides of the cube).

I did look into Evak's suggestion, but as I suspected it caused the bumps to invert all over the box, so that some sides were still being lit wrong. A good suggestion, but not a solution.

I ran it by Eric (Chaster), via email. He wasn't seeing the problem at first, until I sent him this image for comparison:



The normal mapped bricks in the above image look correct. See how the bricks have highlights on the upper edges, and on all sides? That's what I'm trying, and failing to get oFusion to do.

The above image is of the same box under the same lights, but the shader was created using ShaderFX. The screen grab is from within Max's viewport.

Now, Eric got a look at an XML version of the box, and he said:

Okay, I think I found your problem(s).

You have 2 textures on the box, one is (I assume) the base texture, the
other is the normal map, correct?

1) One texture has U,V coordinates, but the other one has U,V,W,
coordinates. That is not only odd, but probably bad.

2) Furthermore, the 2nd texture (which has UVW coordinates) has some
vertices with negative values for U and/or W. That means that the texture
is flipped compared to the other vertices (which have positive U & W
coordinates).

So, it seems to me what is happening is:

Your normal map has been improperly mapped onto *some* of the cube faces
(vertices). This is illustrated by the negative UV values. Negative UV
values are of course, still valid, but they result in flipped orientation.
Since only SOME of the verts (and therefore faces) have negative UV values,
this is why you're seeing the "lit from below" artifacting on only some of
the faces.

Eric

That didn't entirely make sense to me as I'm a non-techie, but I can say for sure that the box was mapped as properly as I could possibly get it, within 3ds Max. This cube is the most basic default cube possible, with default mapping. Which perhaps points to Max as the culprit, since Max, as Eric points out, "is notorious for all its 'cruft' that it has accumulated over the years since it is literally based on code from back in the DOS days." However, that doesn't explain why the ShaderFX shader works just fine. If the cube was the culprit, wouldn't the ShaderFX shader have the same problems I'm seeing in the oFusion shader?

Have you tested the shaderFX converted shaders in oFusion?

Post your shaders if you need them to be converted

Hi Lioric,

I haven't tested the ShaderFX shaders in oFusion. I'm not actually trying to use the ShaderFX shaders in oFusion. (I might someday, but not yet.) I was just posting the image of the ShaderFX shader to provide an example of how the bricks should look.

The bricks in the normal map shader in oFusion appear to me to be lit from below, when they should be lit from above. Are you seeing this? If so, can you suggest a fix within the shader? It's the Monster shader (which was the one that I think was suggested as the best option for the normal maps).

Your mesh should use the same uv's for the diffuse and normal map textures

There is no problem with the uvw channel, as internally the mesh will use the uv components for that channel, but the issue might be related to the negative u or v values as this channel is used by the normalization maps

In any case its recommended to use the monster shader, for performance and advanced options, if you want to use this shader with shadows you need to comment out the sampling of the diffuse texture section of the shader, and use the diffuse image as you are using it now with your current material (in a different pass)

Hi Lioric,

Have you tested the shaderFX converted shaders in oFusion?

Post your shaders if you need them to be converted

I'd like to take you up on that. Here's the shader (the entirety of the contents of the .fx file, I hope that's what you need):



/*** Generated through Lumonix shaderFX by: Owner in 3dsmax at: 9/5/2007 2:21:30 PM ***/


float4 DiffuseColor
<
string UIName = "Diffuse Color";
> = {1.0f, 1.0f, 1.0f, 1.0f };


texture TextureMap_9148 : NormalMap
<
string Name = "N_cobblestones_ati.dds";
string UIName = "Normal Map";
string ResourceType = "2D";
>;

sampler2D TextureMap_9148Sampler = sampler_state
{
Texture = <TextureMap_9148>;
MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = LINEAR;
};



/************** light info **************/

float4 light1Pos : POSITION
<
string UIName = "Light 1 Position";
string Object = "PointLight";
string Space = "World";
> = {100.0f, 100.0f, 100.0f, 0.0f};

float4 light1Color : LIGHTCOLOR
<
> = { 1.0f, 1.0f, 1.0f, 1.0f};

//----------------------------------
float4x4 wvp : WorldViewProjection < string UIWidget = "None"; >;
float4x4 worldI : WorldInverse < string UIWidget = "None"; >;
float4x4 worldIT : WorldInverseTranspose < string UIWidget = "None"; >;
float4x4 viewInv : ViewInverse < string UIWidget = "None"; >;
float4x4 world : World < string UIWidget = "None"; >;

// input from application
struct a2v {
float4 position : POSITION;
float3 tangent : TANGENT;
float3 binormal : BINORMAL;
float3 normal : NORMAL;

float2 texCoord : TEXCOORD0;

};

// output to fragment program
struct v2f {
float4 position : POSITION;
float3 lightVec : TEXCOORD0;

float2 texCoord : TEXCOORD1;

};

//Diffuse and Specular Pass Vertex Shader
v2f v(a2v In, uniform float4 lightPosition)
{
v2f Out = (v2f)0;
Out.position = mul(In.position, wvp); //transform vert position to homogeneous clip space
//this code was added by the standard material
float3x3 objTangentXf; //build object to tangent space transform matrix
objTangentXf[0] = In.tangent;
objTangentXf[1] = -In.binormal;
objTangentXf[2] = In.normal;
//this code was added by the standard material
float4 osLPos = mul(lightPosition, worldI); //put world space light position in object space
float3 osLVec = osLPos.xyz - In.position.xyz; //object space light vector
Out.lightVec = mul(objTangentXf, osLVec); //tangent space light vector passed out

//this code was added by the texture map Node
Out.texCoord = In.texCoord; //pass through texture coordinates from channel 1

return Out;
}

//Diffuse and Specular Pass Pixel Shader
float4 f(v2f In, uniform float4 lightColor) : COLOR
{
float3 ret = float3(0,0,0);
float3 L = normalize(In.lightVec); //creating the light vector

float3 input2 = DiffuseColor;


float4 TextureMap_9148 = tex2D(TextureMap_9148Sampler, In.texCoord.xy);
TextureMap_9148 = TextureMap_9148 * 2 - 1; //expand to -1 to 1 range
float3 Normalize = normalize(TextureMap_9148.rgb); //Normalize
float3 input8 = Normalize;

float3 N = input8; //using the Normal socket
float3 diffuseColor = input2; //using the Diffuse Color socket
float diffuse = saturate(dot(N,L)); //calculate the diffuse
diffuseColor *= diffuse; //the resulting diffuse color
ret += diffuseColor; //add diffuse light to final color
ret *= lightColor; //multiply by the color of the light
float4 done = float4(ret, 1);
return done;
}

technique Complete
{
pass light1
{
VertexShader = compile vs_1_1 v(light1Pos);
ZEnable = true;
ZWriteEnable = true;
CullMode = ccw;
AlphaBlendEnable = false;
PixelShader = compile ps_2_0 f(light1Color);
}

}



This is a shot of the shader from within 3ds Max:



This will be a huge help to our project if we can get this pipeline worked out. Thanks very much for offering to help!

-Spencer

HEllo PDX

If Monster Could be Lightmapped, would be fantastic, but monster 1. The one that works with oFusion has no lightmap support.

It works perfectly with the lights and lits where it is supossed to be lit.

You´ll find some screens and a video here:
http://www.ogre3d.org/phpBB2addons/view ... ght=normal

Also I found a very weird fail in shaded scenes.
In a fully working scene, with a ground normal mapped, when I entered a Toyota celica for testing, everything was working ok.
BUT, when I lightmapped the car and applied the lightmap in channel2, the car appeared lightmapped BUT the RT shadows became crazy as long as the slightlyest part of the car was inside the viewport, and as far as the lightmapped car came out, everything came again to normality.

I sped many hours trying to solve this as an artist and I lost them all.


I´ve prepared some shots of this issue:

working TT with RT shadows.




Non workint TT with lightmap, scene shadows crash.




VIDEO of the problem
http://www.ikernor.com/download/ogre-forum/ofusion/normal-mapping/monster-test-3/problema-monster-shader-tt.rar
__________________-
For LIORIC
HEllo, doing this test I´ve noticed that groups still dont work in CE wich are supossed to be working. When I group the TT it dissapears, and as fast as I ungroup, it appears in the viewport without updating...
I´m using the latest version, but I´m sure that in the previous it didnt work also.

bye.

You can try adding the lightmap to a different pass and changing the render order of the passes to stop the fighting.

I don't know how to add a lightmap to shaders either. It's really easy in shaderFX but most shaders take me 3/4 tries over a couple of days to convert, if I do it myself. Mostly guess work and trial and error since I am rubbish at coding.

Seems to me shaders are the last real problem for artists wanting to use Ogre. They really are a pain even for experienced artists. Especialy on low budget/no budget projects where you cant hire coders to convert them for you

Hope someone eventually tries to make better compatibility between ogre and standard FX formats. Everyone I know has been struggling for months trying to use shaders, and some have changed engines if they need shaders, since many now support FX files out of the box.

Have been tempted myself but Ofusion is so good at handling everything else, I stuck with Ogre so far.

Well, it sounds like a tricky problem, but at the same time it sounded like Lioric would be able to convert the ShaderFX shaders to oFusion (which is why I posted the shader three posts back). Lioric, are you able to convert that shader?

I will convert your shader

As soon as i have some free time (hope during this weekend) i will provide you the oFusion version of your shader

Hey.

Could this be public?

I would kill for a lighmaped normal map shader>>

bye

I created a shader in shaderFX with the same values as the screenshot (except the normalize node)

This is the shader produced by oFusion with the upcoming shaderFX support

File: nm.program



fragment_program normalMapFromSFX hlsl
{
source nm.source
entry_point f
target ps_2_0

default_params
{
param_named_auto lightColor light_diffuse_colour 0
param_named UIColor_1521 float4 0.768628 0.768628 0.768628 1

}

}

vertex_program normalMapFromSFX hlsl
{
source nm.source
entry_point v
target vs_2_0

default_params
{
param_named_auto lightPosition light_position 0
param_named_auto world transpose_world_matrix
param_named_auto worldIT inverse_world_matrix
param_named_auto wvp transpose_worldviewproj_matrix

}
}




File: nm.source


struct a2v{
float4 position : POSITION;
float2 texCoord : TEXCOORD0;
float3 tangent : TEXCOORD1;
//float3 binormal : BINORMAL;
float3 normal : NORMAL;
};
struct v2f{
float4 position : POSITION;
float3 lightVec : TEXCOORD0;
float2 texCoord : TEXCOORD1;
float3 worldTangent : TEXCOORD2;
float3 worldBinormal : TEXCOORD3;
float3 worldNormal : TEXCOORD4;
};
uniform float4 UIColor_1521 = {0.768628f,0.768628f,0.768628f,1.0f};

uniform sampler2D NormalMap_6116Sampler;
//uniform float3 light1Pos : POSITION = {100.0f,100.0f,100.0f};
//uniform float4 light1Color : LIGHTCOLOR = {1.0f,1.0f,1.0f,1.0f};
uniform float4x4 wvp : WorldViewProjection;
uniform float4x4 worldI : WorldInverse;
uniform float4x4 worldIT : WorldInverseTranspose;
uniform float4x4 viewInv : ViewInverse;
uniform float4x4 world : World;

#line 80
v2f
v(a2v In, uniform float3 lightPosition)
{
v2f Out = (v2f)0;
Out.position = mul(In.position, wvp);

float3 worldSpacePos = mul(In.position, world);

Out.lightVec = lightPosition - worldSpacePos;


Out.texCoord = In.texCoord;
//t.texCoord.y += 1.0f;
Out.worldNormal = mul(In.normal, world).xyz;

float3 binormal = cross(In.tangent, In.normal);
Out.worldBinormal = mul(binormal, world).xyz; //compute world space binormal
Out.worldTangent = mul(In.tangent, world).xyz;

return Out;
}

#line 100
float4
f(v2f In, uniform float4 lightColor) : COLOR
{
float3 ret = float3(0,0,0);
float3 L = normalize(In.lightVec);

float3 input2 = UIColor_1521;


float4 NormalMap_6116 = tex2D(NormalMap_6116Sampler, In.texCoord.xy);
NormalMap_6116.xyz = NormalMap_6116.xyz * 2 - 1;

float3 Nn = normalize(In.worldNormal);
float3 Tn = normalize(In.worldTangent);
float3 Bn = normalize(In.worldBinormal);
NormalMap_6116 = float4((Nn * NormalMap_6116.z) + (NormalMap_6116.x * Bn + NormalMap_6116.y * -Tn), NormalMap_6116.w);
NormalMap_6116.rgb = normalize(NormalMap_6116.rgb);
float3 input8 = NormalMap_6116.rgb;

float3 N = input8;
float3 diffuseColor = input2;
float diffuse = saturate(dot(N,L));
diffuseColor *= diffuse;
ret += diffuseColor;
ret *= lightColor;
float4 done = float4(ret, 1);
return done;
}



Paulov: I will add lightmap support to the Monster shader (1 or 2)

Paulov: I will add lightmap support to the Monster shader (1 or 2)

That would rock sooo much!

I'm currently struggeling with this approach: http://www.ogre3d.org/phpBB2/viewtopic.php?t=34913
but I can't get it to work properly with my app... besides, this would mean I'd have to rewrite all the materials ofusion created so that they fit the other shader :/

Do you have an idea "when it's done"? ^^
(don't want to be barefaced - rather more excited!)

Lioric,

Thanks very much! I haven't had a chance to try it out (and sorry for the slow reply). I'll give it a go this coming week.

Or not... You say,

his is the shader produced by oFusion with the upcoming shaderFX support


Does that mean it won't work with the current version of oFusion?

It will work with the current version, they are the contents of the files produced with a shaderFX setup similar to your screenshot, by the new shaderFX support

Create the files above and copy them to the shader folder, they will be available in the shader list

The normal map will use the first texture coord channel (as if they were the diffuse), the diffuse color will be modified with the "UIColor_1521" parameter, as your previously posted files

You need to enable "Generate Tangent Vectors" for each object you want to apply this shader to

The "param_named_auto lightPosition light_position 0" in the nm.program file might need to change to "param_named_auto lightPosition light_position_object_space 0"

Hey.

Very nice.

Looks like finally the normal map shader arrived.
I´m ultrabusy these days but I´ll try as fast as i´ve a chance to give it a try.

bye, and thanks for the job

Hi Lioric,

I gave the shaders you posted a try. I'm having a few problems.

First off, when I load up Max (9), "normalMapFromSFX" only appears in the Pixel Shader slot of the oFusion Pass. It's not available in the Vertex Shader slot.

Then, after I select normalMapFromSFX in the Pixel Shader slot, I hit "Edit". All I see there is the word "Parameters" with a "-" sign, but no actual parameters.

Just for the heck of it, I click the word Parameters a few times, which toggles the "-" to a "+" sign and back again.

Then, if I click right around the "P" in "Parameters" a green A and the words WORLD_MATRIX appear. At which point 3ds Max crashes.

Obviously, something is wrong here.

It could be something I did wrong, of course, but all I did was copy the shaders you posted to the file names you posted, and tried to load them into Max. I double-checked, and I'm pretty sure I did this correctly.

Again, this is in Pro version. I'm an artist, not a programmer. I've done all the tutorials, but I'm never sure I'm doing things correctly.

A sample Max file, with sample shader files, would be hugely useful. Would it be possible for you to post something like that?

Thanks,

Spencer

Change the name of the vertex shader, in the file nm.program, from "vertex_program normalMapFromSFX hlsl" change to "vertex_program normalMapFromSFX_vs hlsl"

What render system are you using? (shaders are for Direct3D9)

Post your ogre.log file (from the max root folder), after you load the shaders and display the shader parameter editor

Lioric,

What render system are you using? (shaders are for Direct3D9)

Thanks for the suggestions, that helped. Turns out I had the Max viewports set to render with Direct3D, but I had the oFusion viewer set to OpenGL. (I believe I had oFusion set to OpenGL because a long while back there was a bug having to do with character skeletons, and the only workaround was to run the oFusion viewer in OpenGL mode.)

Switching the oFusion viewport to Direct3D eliminated the crashing, and it made your shader appear. Plus, it looked a lot like the one from ShaderFX!

However, there's still the problem I was hoping to solve with all this: the normal maps appear inverted on some parts of the model when viewed in Ofusion.

I've illustrated it in this comparison. The ShaderFX shader (rendered within Max's viewport) looks correct given the location of the light. However, this latest oFusion version of the same shader looks incorrect:



It's the same old problem of the highlights being on the wrong side of the normal-mapped bricks.

The fact that the same problem is happening with two entirely different shaders makes me wonder if the engine is at fault.

Any thoughts?

here's a basic normal map with shiny value converted from shaderFX. I included a max 9 file with a material already set up and a box like yours. It has a shinyness parameter #define that you can edit in the ofusion parameter editor, its at 0.25 by defalt 0 would turn it off.Seems to be working fine here. Hope I copied all the files correctly.

http://www.kineticrealities.com/ShaderF ... nShiny.rar

I don't think our coder will mind sharing this one since its one of the most basic early shaders he converted for me. Can't remember if it was compatible with static geometry. You have to use different ogre auto parameters in your shader to get normal maps to work with static geom and have the shinyness update with the camera position.

Let me know if this shader works in your scene.

BTW, I noticed with the teapot, with the autoUV's the normal map is inverted like yours, but if I add my own UVWmap it comes out correctly, the box worked fine with autoUV's

Evak, that shader worked! Hot damn. Here's what it looks like:



And that's how it SHOULD look.

A couple questions:

It seems that a given object can only be illuminated by one light at a time. If I add a second light nothing happens unless I move the second light close enough to the objects, at which point the illumination from the first light switches off. I see in the material it says, max lights: 8. Is that value being overidden somehow?

Also, I thought I would turn off the sand texture by unchecking its texture unit checkbox. Here's a gif of me doing just that:



This causes the normal map to stop working. Do you know why that is?

What's interesting to me also is that, when I break the normal mapping in this way, the geometry seems to be lit from a different direction. In this case, for instance, the cube goes from being lit on the left face to being lit on the upper right corner. It almost seems to share the mis-directed lighting I was seeing on the earlier normal maps.

Well, many thanks for the help, Evak. You've come through for me more than once!

Edit: BTW, I forgot to mention that I got the teapot to look OK even without remapping it as you suggested. I just checked Generate tangent vectors.

heh, doh. Now you mentioned it, I did the teapot test at the last minute and must have forgotten to turn tangents on.

I'm not too good with shaders, relying on shaderFX to create them, and looking at some examples our coder did already. Sometimes I can convert them myself sometimes I cant.

You can only use 1 light because when we made the shader it was for an outdoor scene with just one light. I would have to change the number of lights in shaderFX to support extra ones I think.

with the diffuse texture, I never tried it without before. I do know that shaders are very specialized and specific. So often you don't have the flexibility of changing anything without editing the shader source code and data streams that it's using. I expect the reason the normal map failed was that the shader was looking for the diffuse map and when it couldn't find it the shader was broken.

Evak,

Can you suggest a way of adding a shadow map to that normal map shader? That was my intent all along, to combine a diffuse, normal, and shadow map.

I did a few experiments with your shader, trying to add the shadow map as both a pass and a texture unit. The pass doesn't blend well, but instead looks like a horribly sorting polygon layer. The texture unit doesn't show up at all.

I went in shaderFX and multiplied a quick lightmap with the diffuse map, and looking at the FX file it created it was only a couple of lines of code that were different. Copying and pasting those into the old shaders seems to have worked.



I updated the old archive with the new files, so theres both shaders for ofusion and a new max file already set up. you can see the lightmap working on the plane in the pic above.

I didn't try adding extra lights or anything. Lioric showed me a vid of shaderfx working in Ofusion. It looks very promising and I'm hoping that that will lead to a really nice solution for creating DX shaders for Ogre. For those willing to pay for both shaderFX and Ofusion Pro.

Evak,

Thanks so much, that shader looks like it might be just what I need. I haven't had a chance to try it out with my textures, but I will in a bit. Much appreciated.

I didn't try adding extra lights or anything. Lioric showed me a vid of shaderfx working in Ofusion.

I saw where you mentioned this in another thread. That would be nice to have. Any idea of an ETA?

It looks very promising and I'm hoping that that will lead to a really nice solution for creating DX shaders for Ogre. For those willing to pay for both shaderFX and Ofusion Pro.

Count me in. I already bought oFusion Pro, and I was getting ready to pick up ShaderFX.

-Spencer

Evak,

This is an awesome shader (better than anything I can do right now). but I did find one thing.

Either I did something wrong, or this shader can't support multiple uv channels. I usually place my light maps on a secondary uv channel, so I can optimize uv layouts. I also noticed that I could not tile the normal map

Here are screen shots of what I mean...

Just lightmap, no shader


With shader


If I have done something wrong please let me know. again this is a great shader (especially for us artists who don't know shader languages )

shaders don't work like regular materials. You can't just add a UV to your model and expect the shader to recognise it in the shader.

The shader is already using 3 UV channels at the moment for streaming different data. Only one of those is for the mapping coords, the shader uses two others internaly, one for calculating the light vector, and the other the camera vector so that the normal map and shinyness dynamics are calculated correctly.

To add a 2nd UV channel, you have to add it to the shader source code, just like you have to add extra code to allow extra lights. I might try and add an extra UV channel, not sure if my coding is up to it, unless its as simple as copying and pasting a couple of lines from shaderFX's .FX file.

If I add 2 UV's then it means that a material with only 1 UV on the model (like a skinned object like a character) will break the shader.

Ok, I was just checking if it was, me or not thanks

OK I managed to add a second UV to the diffuse and normal map.



I uploaded a new version of the archive, it contains the 2UV version of the shader and a max scene. I changed the textures in the above screenshot so you could see the tiling normal map better, the file in the archive uses the same textures as before.

So to recap, there are 3 shaders now.

Shiny Normalmap
Shiny Normalmap + LM (1UV for all textures)
Shiny Normalmap +LM (lighmap UV1, Normal and Diffuse UV2)

If you need to mix and match techniques, you need to make new materials with the right shaders assigned to each.

BTW. I didn't know I had it in me to fix those things so thanks for the inspiration to try. Took me an hour to add the extra UV since I'm an artist and not a coder. Was pretty simple in the end.

Thanks a lot!

Wonder how you would go about getting the dynamic lights to fade out the lightmap. Thats the only thing wrong with a straight lighmap/normal map shader.

Maybe Lioric knows.

I have put thought into it, and my solution while not really dynamic, does provide something of a solution.

If you know the position of the light (and where it can and cant go). then nothing is stopping you from rendering out a series of light maps and animating the lightmap.

My work bench when complete, will have four light maps.

both lights off
one light on
the other light on
both lights on.

it becomes a programing issue to swap out the materials, but I think it would still be more cost effective for the machine running the program.

I bought the making of gears of war art book, and they did something similar to this for a lot of lights. The lights on the armor for instance were turned on and off by animating the position of a a 1 X 2 pixel image (one pixel black the other white).

When the white pixel was moved into position the lightmap shown through, when it was on the black position, it was the sam as the light being off.

Yeah, that does seem like a resource friendly way to do it so long as you don't have a flashlight or something that the player moves it would work well.

hi.

I´ve downloaded the shaders EVAK made public, and when running the scene the following error appears when Ditect 3D is activated:

Cannot assemble D3D9 high-level shader w_Ambient Errors: (48): error X3004: undeclared identifier `attend0´

after that, max crasehs.

I´ve downloaded the latest card drivers, and had the same error.
And latext DX9too...

Any ideas¿?=¿?=?

hmm, I don't know. The shaders have no ambient paramaters or attend0 in the source. Perhaps you are loading something else in either the pixel shader or vertex shader slot.

Don't get any shader errors at all in my ogre.log in the max root.

You should look in your ogre.log incase you have another material or shader creating the error.

When you say direct 3d is active, is that the direct 3d in the ofusion settings or 3d max settings? I have found (through personal experience) that both need to be set to directx. If you run max in open gl, and the ofusion window in direct 3d it could cause problems (at least it has done so for me).

One time I couldn't get ofusion to load because I turned on my bluetooth device...

Geat shader Evak, excellent job, this will go directly to the new wiki (and the shader library)

Animating a spotlight/flashlight is easier than other type of lights when combined with LMs, for this you can use a projective texture (the image of the spot light or the flashlight), you wont use the light object (other than the position and direction), but the light texture, and add another pass with this projected texture to the scene objects were the light intersects, this image can be blended with "add" to the existing scene light

This is similar to creating marks on the walls (paint, holes) but you update the same pass with the position of the light (with a different scene blend mode to create the effect)

Another method is using the shadow system (texture shadows), but with a custom shader material you invert the shadow texture, this creates a light texture that is applied to the complete displayed scene

Odog87: You dont need to create multiple textures with all of the combinations for your lights, you can create a single LM texture for each light, and then blend them in the fragment shader, if light1 and light2 are on, sample each texture and blend them with the correct blend mode

For animating, you can create textures at defined time intervals (not each frame), for example for a light moving in a room from side to side, you can create a LM in each side and a LM in the middle of the room, then blend between them in the fragment shader depending on the light position
If you prefer you can create a single volume texture with all of the texture frames for a light in it (or with the static LM for multiple lights), this way you dont need to modify the material state (changing textures or animating frames) and can support an increased number of lights (32, 256)

reinstall max + reinstall oFusion= problem solved.

EVAK!!!

IMPRESIVE SHADER!!!!

WOOOW!! I´m very busy these days But sure I find a moment to play with this.

Hey, did you do the normal map yourself? If so--> looks very whell done with the heighs very nicely generated.

I´m having some issues when generating new lightmaps, I´ll keep on playing and post tomorrow.

well done!

I couldnt wait more:


http://www.ikernor.com/download/ogre-fo ... ader-3.jpg
http://www.ikernor.com/download/ogre-fo ... ader-4.jpg
http://www.ikernor.com/download/ogre-fo ... ader-5.jpg
http://www.ikernor.com/download/ogre-fo ... ader-6.jpg
http://www.ikernor.com/download/ogre-fo ... ader-7.jpg
http://www.ikernor.com/download/ogre-fo ... ader-8.jpg

The last two shots show the test I made with the mapping tools I use for thngs like roads. It worked well after a bit of tuning, but the tool does not map the channel0 wich I think is the one of the lightmap. anyway looks like it will be posible... but I dont have time now.

The parameter to control the shinnies, is wonderfull, is something I really missed in monster.
Now, just one question, If I want materials with the same shader effect but with different shinnyes I have to make different copies?

Anyway . Thanks EVAK for this great job.

enjoy the pics.

Hey that looks good

With the lightmaps, you have to set the lightmap on channel 1 using UVWmap or UVWunwrap modifiers. You don't have to change the channel in the ofusion texture unit or anything, the UV channel is hard coded inside the shader.

I may update the shaders one more time during the week with optimized shaders that will work with static geometry too.

I'd be tempted to put together a shader pack or something, but to be honest I'd feel like I was ripping off ShaderFX. My coding skills are in the script kiddie realm of coding and I think shaderFX should get maximum credit for making things so much easier that even I can just about get by with these more straighforward ones.

Geat shader Evak, excellent job, this will go directly to the new wiki (and the shader library) Wink

Is there a link to the WIKI that you are talking about?

Also, after reviewing EVAK's shader converted from ShaderFX, I plan on purchasing ShaderFX. But I would like to know if there is some sort of documentation on how to convert a shader to be compatible with oFusion

the nearest thing to a tutorial is the one professor 420 wrote.

http://lumonixsoftware.com/yabb/YaBB.pl?num=1179634232

BTW if you want to see how lioric has been integrating ShaderFX into ofusion. He sent me a video showing basic functionality. I will stick it up on my web server so you can get an idea of how it will work.

I may have to take it down later since I havent asked permission to share the vid. It's showing simple shaders, but its very cool and shows that this will be an excellent tool if the many shaderFX features can be supported.

It's not a streaming vid, for best results right click on the link and save to your HD before playing back.

http://www.kineticrealities.com/shaderfxsupporttest.avi

At the moment you have to convert your own shaders by hand, I found professors tutorial and Liorics rendermonkey tutorial plus some shaders my coders coded for me a big help.

Hi-<

I´ve been playing with the shader, now shading objets.

I´ve modelled a traffic cone.


Before this I´ve been mapping an scene with different objets shaded. Have to say that is WAY better to have them shaded independently with just that objet in-scene than doing all in the "big" one. Finally weird things started to happen and I finally gave up.

The trafic cones:

One of the first test I´ve made has been to have different cones with different shader properties = shinnies. An it has worked correctly, so there is no need to have different shaders with different configs.

I dont know how much resources does the shadder consumpt, but sure that a simple textured objet, so I made a LOD for the material.
THe ideal would be an objet LOD where the second LOD level would be a simple textured objet with the cone formed by a billboarded plane.

This trafic cone has a reflecting strip in the midle of it. So the cone is visible when hit by a carlight, but if the shinnies is set over 0 all the conne starts reflecting, wich is not correct at all.
I´ve tried to control the shinies by obscuring the normal map, but if in some parts of the texture has worked not in others (weird).
I think that the addition of the specular mapping feature would be very welcome, as this way the materials would shine logically.

I.e: The floors if composed by rock pieces will be sticked with mortar, wich is not specially shiny surface, but the rocks can have shinny surfaces.

One difference I´ve noticed betwen the normally textured and the shaded cone is a variation of its color. The shaded is considerabily darker and in the faces where the light does not hit directly they are very (too) dark.
Even if changin source blend the color variations can be obained, none offers a bright ressult.
- Changing the color blend to modulate 2x etc does not affect the ressult.

What I´ve done to minimize the contrast effect betwen the LOD levels is change the simple textured material color blend from one to source color. (shown in the video)

Here some screens of the scene and from the normal mapping variation ressults, and a video to show the things commented before.

www.ikernor.com/download/ogre-forum/ofu ... oments.jpg

ftp://ftp.ikernor.com/ikernor.com/downl ... onevid.rar
www.ikernor.com/download/ogre-forum/ofu ... onevid.avi

bye_
have a nice day.

Hi guys,

great work - looking forward to trying this out myself.

Unfortunately, I'm running 3ds 8 here. Could you save the scene for 8, or better still provide a .material file for 3ds, assuming that that's downward compatible. An exported scene from oFusion would also enable people to try out the shader, even if they don't have 3ds.

Anyways, I have some models with nice normal maps and specular maps and would love to finally be able to use them with a shader that supports both

I also took a look at ShaderFx today and plan to get a licence. Did any of you try out the relief shader (or any other advanced one) with oFusion?

BTW: on the ShaderFx website I read something about integration with Quest3d (which we hated and dropped in favor of ogre). I don't know about the quality of the integration but it suggests that a smooth integration with a render engine should be possible.

Anyways: all the best with this! If I can try out the shader with 3ds 8 I'll provide some feedback

Markus

HEllo Fum. Welcome.

The shader was posted previously.
There are several versions that vary in having lgihtmap property or not.

The shader is available in this threat some post back, posted by EVA, its a max scene. If you cant open it tell me and I´ll provide the material, but try it before. (downgrading is possible?) The link started as www.kinetikrealities.....

The first texture slot is for; Lightmap
THe second one for: Difuse
The third for: Normal map

I recommend you to rename the slots as Lightmap, Difuse etc and save a template material to the library, is what I did , just this tip.


few posts back Evak posted a video of the conectivity betwen shaderFX and ofusion:
http://www.kineticrealities.com/shaderfxsupporttest.avi

To me the ressulting shader is very simple, but its an step forward and in a phsase of "work in progress".

Hope see your work round here.

I´m willing to try that shader FX soft, as fast as I have some serious free time.

Hi, the shaders I posted are dark in part because they have no ambient light color parameters. So ambient is always black. ShaderFX creates the ambient and self illumination in a seperate pass, I havent played with those aspects yet.

I do have a specular map version of the shaders I posted. It has the specular map stored in the diffuse maps alpha.

Hi guys,

I had downloaded Evak's package and tried to load it but the 3ds9 files won't open in 3ds8.

I will upgrade at some point but for now a material file would be great.

Once I have it working I will have to ask you how I store a specular map in the alpha channel of a diffuse map. Is there a specific reason for doing it this way?

Best,

Markus

PS: my nickname is fumé (e with an accent at the end) which I thought was very smart but phpbb didn't seem to agree

I think putting it in the alpha is more efficient and using less instructions to process than a seperate texture.

Your already using the RGB channels for diffuse color, and grabbing the alpha is trivial compared to adding another texture stream and reading the 3 RGB values to get the specular when alpha is only one channel.

I havent put up the specular map shader on here yet though.

Hello

I´m in Barcelona, and I´ll be here for some days-weeks more.
I´ve no 3D hardware but I visit the forum almost everyday.
I see that this threat thas has been on fire for weeks and now it looks a bit freezed.

Would be fine to know if people if making tests with this shader and what are their ressults or comments.

Hey evak, any plans to keep the developement of this shader for public access?

I think that the main lacking features for this shader to be fully functional would be:

-->specular mapping.
-->ambient light control--->with the classic color palete, selecting the tone and the brightness.

A shader like this would cover the major needs of an artist.

I remember that in your previous releases you´ve released "downgraded" versions without lightmapping. I would like tu know wich is the less resource consumming technique if there is difference.

1)
use the same shader for all the scene, with different configs as:
lightmapped materials use a lightmap.
unlightmapped materials use an standard 2x2 like white texture map.

2)
lightmapped materials uste the shader with lightmap.
unlightmapped objets use shader without lightmap , so total 2 shaders.

bye bye.

I will comment on your performance question,

Specialization is the key for performance in 3d, the less render states you make to render an object, the faster it will be (a render state can be switching textures)

It will be faster to have different shaders that do exactly what the object needs, in your case the #2 method, because with the other method (a single shader for all of your objects) even when you put a small dummy texture to non-LM materials, the render state will be changed for the new (2x2) texture and the fragment shader will sample the texture for the visible pixels of the object and then do filtering