_normal map problem? Created 15 years ago2008-09-25 12:00:10 UTC by The Mad Carrot

On the left, a normal texture without a normal map, dudv map or anykind of map. Everything fine there.

On the right, the same texture but WITH a normal map. As you can see, the light is differs from the one the left. Why doesn't it look circular like the light on the left?

The normal map was created with ShaderMap Pro
I also tried the automatic normal map creator included in Nem's VTFEdit tool, but that also creates the petal shape like you see on many flowers.

Also, whats the difference between a normal map and a bump map?

I think Normal does nothing (a "flat" look) and Bumps bring out the texture (making it rougher/more realistic - like running hands accross stuco or concrete for example).

What type of lght you using? Are you also at exact same viewing location and light has same parameters?

The light is just a light entity. The light on the right is an exact copy of the left light.

I think Normal does nothing (a "flat" look) and Bumps bring out the texture (making it rougher/more realistic

See, thats what confuses me:
The texture on the right has this additional blue/purple-ish texture with _normal at the end of the name. This texture does what you're saying: making it look rough/more realistic. Yet, you call that a bump map. But Source calls it a normal map, but you said that a normal map does nothing. But it does.

I don't get it. Got any exampled on a normal map and a bump map?

In 3D computer graphics, normal mapping is an application of the technique known as bump mapping. Normal mapping is sometimes referred to as "Dot3 bump mapping". While bump mapping perturbs the existing normal (the way the surface is facing) of a model, normal mapping replaces the normal entirely. Like bump mapping, it is used to add details to shading without using more polygons. But where a bump map is usually calculated based on a single-channel (interpreted as grayscale) image, the source for the normals in normal mapping is usually a multichannel image (x, y and z channels) derived from a set of more detailed versions of the objects. The values of each channel usually represent the xyz coordinates of the normal in the point corresponding to that texel.

and that means?

Thanks Hunter. So a normal map and a bump map are the same thing?

So the right texture has a normal/bump map, but the light on it differs from the one on the right, almost like a flower shape.

I still need to know why its doing that. I want the same circular light like the one on the left.

normal map is the texture you use to bumpmapping. Bumpmap is the technique. But normal maps are also used to other things like parallax mapping, which is a better version of bumpmaping.

Parallax

Thanks, Spike.

(Helping someone is much more fun then spamming the shoutbox eh? :D)

Better example about parallax mapping:Notice all 3D you see is a flat texture.

And helping other is just fine when you have nothing else to spam.

But why is my light on the right all weird?

Maybe it's reflecting the light in the way it looks like this...

Check the compression on your normal map. For the best results normal maps should use either fine compression, or no compression, but this can make the _normal.vtf file quite large. I've noticed that normals that are too heavily compressed can throw lights out wierdly, you might notice the normal comes out perfectly in one direction, but artifact-y and uneven in a different direction.

There's a flag you can use when compiling your textures, I'm assuming you're using VTFEdit to do so?

Tick "No Compress" and make sure you import your normal with a suitable image compression, RGBA8888 will give the nicest (and largest) result, but the others should work ok with No Compress.



Also.. Parallax Mapping is ugly as sin.

Ok, so i import my texture as follows:The default setting for Normal Format was DXT1. I changed that to RGBA8888, like you said.
The default setting for Alpha format is DXT5 and left it like that.

So i click ok, but there's no "No Compress" flag in VTF edit:I checked the Normal Map checkbox myself and Eight Bit Alpha (Format Specific) was checked by default.

VTF version is 7.4.

And the results are still the same? If so, it's probably not the compression at fault.

Delete the light sources, replace them, recompile, then type:

sv_cheats 1
mat_reloadallmaterials

It'll refresh everything, including the lightmaps. If that doesn't work then I'm not really sure what's going on. Would you mind posting the .vmt up here? It might help (or it might not).

I never found the "No Compress" flag.

mat_reloadallmaterials didn't work.
Is that the same reload_materials 1?

Here are my source files:
http://www.themightyatom.nl/stuff/normal_map_problem.zip

Contents:

mapsrc/x.vmf (the level)
materials/temp/concrete_launchpad.tga (base texture source image)
materials/temp/concrete_launchpad_normal.tga (normal map texture source image)
materials/temp/launchpad_conc.vmt (material file for the normal texture (no bumpmap)
materials/temp/launchpad_conc.vtf (texture file for the normal texture (no bumpmap)
materials/temp/launchpad_conc_norm.vmt (material file for the bumpmap version texture)
materials/temp/launchpad_conc_norm.vtf (texture file for the bumpmap version texture
materials/temp/launchpad_conc_norm_normal.vtf (normal mat texture for the bumpmap version)

This is for the Orange Box engine, HL2:Ep2 preferable.

Hopefully you can figure this out.

I'll give it a look over.

Thanks, and while you're at it, have a look at this thread on the Steam forums, i posted the same issue there: http://forums.steampowered.com/forums/showthread.php?p=8201830&posted=1#post8201830

Read the 6th and 7th post.
Im starting to think that this is a bug in Source.

Finally got around to this, sorry it took a while.

I could open all your .vtf files, but for some reason the .vmt's wouldn't work. Like they were corrupted or something, I'm not sure.

Anyway, I did up new material files and recompiled the map with them, and I had to manually compile a new normal map because I remembered that Nem removed the "No Compress" flag, for some reason.

It turns out the lighting is absolutely fine with HDR enabled, but goes awry when it's off (I scaled the bumpmap up so it's more noticable):To me, this says the materials aren't the problem anymore. I'll keep looking into it, but I guess I now know this has something to do with the way LDR lighting works with normal mapping in the engine. Restricting users to HDR isn't exactly great.

Anyway, here's the new ones I did up with no compression, just incase you wanted them. They go in materials/temp like your originals.

Stider, man, thats awesome!

So, to recap, my textures were not the problem, neither is ShaderMap Pro, the application i use to generate the normal map texture.
So how did you made and compiled your normal map texture and used no compression?

I still find this kinda weird.

My original vmt file doesn'nt have quitation marks, like this:

[quote]"LightmappedGeneric"
{

$basetexture	temp/launchpad_conc
$detail		detail/noise_detail_01
$detailscale		7.75
$detailblendfactor	0.8
$detailblendmode	0

}[/quote]

Except for LightmappedGeneric, everything else is not quoted.
Could that be the reason that you were unable to open my vmt files?
Are quotations actually necessary?

Edit:
I can't get it to work on my end. Even with HDR enabled, the light is still weird. And i used your normal map texture. I did made changed to the vmt though:

[quote]"lightmappedGeneric"

{

"$basetexture"      "temp\test_concrete2"
"$bumpmap"          "temp\test_concrete2_normal"
"$surfaceprop"      "brick"
"%keywords"         "temp"

}[/quote]

Im pretty sure there's nothing wrong with that vmt. So i don't get it. :/

Edit2:

Its still not 100% correct, i guess:(This is an edited image of your screenshot)

Notice that the arrows point at area's that have lower bumpmapping, and the red dots mark the area where there's a clear bumpmap effect. When you look at it this way, you still see a petal shape in it. The bumpmap effect should be a circular and have an even bumpmap effect all around the light.

Unless this is normal behavior, i really don't think this is how a bumpmap should look like ingame.

Maybe i just have an eye for detail... :/

Actually.. I do see that now. This honestly has me quite stumped.

Try rotating the texture 45 degrees (or something a fair bit off), if the "petal" formation shows up in the exact same position, then I'm willing to bet it's Source's lighting playing up.

EDIT:
This might be the cause, and I can't believe I never thought of it before.This is the heightmap for the normal, ShaderPro would've generated something similiar based off the diffuse texture. You'll notice some areas come out darker than others, which would end up being deeper, and therefor letting more light 'in'. It just seems very exaggerated.

I'll try evening up the heightmap tomorrow and compiling a new normal map, see how that goes. It could be the problem, but we'll see. If it is the case then the normal maps and Source's lighting are actually doing what they're supposed to be doing.

Could that be the reason that you were unable to open my vmt files?
Are quotations actually necessary?

Well, they are, but I don't imagine they're the reason I couldn't open them. I would have probably received some sort of syntax error for that.

So how did you made and compiled your normal map texture and used no compression?

I used the original vtex.exe method, with a targa and a txt file defining how to create the vtf. The txt simply had:

"normal" "1"
"nocompress" "1"

Which told it to convert it to the appropriate format for normals, and to completely bypass nice filtering/compression. Makes the file large, but gets rid of any artifacts people sometimes get with their bumpmaps.

Ok.

So normal maps (the blue/purple texture) is used for bumpmapping
What does a height map do?

Should i add a heightmap into my temp folder and name it concrete_test_height? Or...?

I rotated the texture in Hammer (25 deg) and ingame the petal shape also rotated.

I checked ShaderMap Pro to see if there's a heightmap generation options, but i don't think it has one. It only has support for generating a:

• Displacement map (which is a greyscale map but does not match the one you posted)
• Normal map
• Ambient occlusion map (also greyscale, but doesn't match yours.
• Specular map (also greyscale, no match)
• DUDV map

Thats weird. It does have a lot of tweak options though.

:/

Edit: im still getting the petal shape, even with HDR on.
Lets see what happens when i compile the normal fil through vtex, like you did...

Edit2: Even with vtex, and even with "normal" "1" and "nocompress" "1", the petal shape is still there.

This is getting really annoying.

Parallax Mapping is ugly as sin.

The problem is that it is often overused. GTA 4 makes wonderful use of it with decals and such.

As for your problem Muzz, I don't know if this will help in any way whatsoever but have you tried using Photoshop's Normal Map Plugin?

As for your problem Muzz, I don't know if this will help in any way whatsoever but have you tried using Photoshop's Normal Map Plugin?

Not yet, but i think it doesn't matter since the texture isn't the problem. I think. I don't know.

Ill just wait Strider has to say.

The heightmap is what's used to generate a normal map. It tells whatever normal map program you use what parts are supposed to stick out (the white bits) and what dips in (the black bits), and converts it all to the funny blue normals. You won't need one in there with your textures. I'm guessing ShaderPro does this bit all by itself.

Anyway, the fact that your light formation rotates with the texture makes me think it is the normal map doing it, it will need to be evened up so there are no obvious dips in the height map and final normal. I can try it, but not until tonight once I get home from work.

I see.

But even then, how come i still get the petal shape with HDR on?
Whatever i do, it just does not goes away. :/

Edit:
Please don't forget about this thread, Strider, you're my only hope to get this _normal bullcrap fixed.

Please don't forget about this thread, Strider

Oops, shit. I totally did, sorry.

Anyway, I did get around to evening up the normal map, and here it is. Just rename it and replace the normal map you're using currently.

It should light a lot more evenly. If you're still getting the problem after this, then I'm afraid I'm completely out of ideas. I really don't see any other reason why it would be occuring, sorry.

Its still doing it! Godamn normal maps!

Time to contact Valve. They'd better reply, darn it!

Time to contact Valve. They'd better reply, darn it!

They did'nt.
So yesterday i continued this experiment because i have a new pc with a different videocard, and guess what?

THE LIGHT IS STILL MESSED UP!

So it's not a videocard issue. Im starting to think, maybe the way im making the normalmap texture is wrong?

Here's what im doing.

I take the texture, load it into ShaderMap, generate a normalmap texture from the original (which is called the difuse texture right?) texture, save it as tga, compile it etc...

But yesterday i was reading about another method of creating a normalmap and that the above method is not how its supposed to be done.

You're supposed to take the difuse texture, generate a heightmap (which is a greyscale texture right?) from the difuse, and then generate a normalmap from the heightmap.

This bullshit is driving me nuts!

Well, I use photoshop but what I usually do is greyscale the original texture so that I have a better idea of which areas are higher than others (altering if necessary) and then sharpen the whole image before create a bumpmap using PS's NVidia Plug-ins.

And how does the light look like when you place one above your texture? Does it look like the one way up in the first post?

I've no idea. I mostly use them for skins. I'll try it out though.

I just downloaded a free texture pack for Source made by the_best_flash and the weird lighting appears on those as well (the ones that have normal maps).

What.

Perculiar

Right you are.

As asked here:

Are you familiar with that dreaded petal shaped light when you place a light entity in front of a wall that has a normal map?

As seen here.

I can confirm that this happens to me too:

LDR:HDR:My guess is that it's probably a glitch in the engine. If it's not, heh... I actually like it. It looks more natural. I guess.

Thanks, i guess that did it.