Bumpmap Artifacts with a Solid Color Bumpmap?

#1 Why are you using a map without any detail in it?

Have you tried removing the map, and just enabling per pixel specular?

Gabriel

#2 I have tried not using a bumpmap, yes, however doing so makes the specular looks really ugly. Check it out:

www.silentluciditi.net/DCalabrese/problemModel_noBump.jpg

It's not smooth at all and really looks nasty, especially on the edges. Which means, bumpmap it is - just how to make it properly smooth?

Thanks,
-Dave C.
21-6 Productions

#3 In the above image did you use the per pixel specular option?

It appears to be only per vertex, hence the edges etc.

How did you generate your flat bump/normal map?

Gabriel

#4 I'd recommend looking into Phong lighting. You get really nice results.

#5 @Gabriel: The above image is using the 'Pixel Specular' flag in Shadergen. I generated the normal map in Photoshop by getting a color and filling a whole graphic in it.

@Matt: I don't believe we're able to use Phong lighting, as the project is very close to being completed and I think we'd have to rip out and replace the lighting system for that.

I should add we're using only Shadergen for this project for maximum per-system compatibility.

Thanks,
-Dave C.
21-6 Productions

#6 You are always going to get a lighting seam along uv edges using any sort of normal map - just the nature of the beast. Id recommend either trying to hide the seam with a color change in the diffuse (itll still be there but slightly less noticable), or exporting out a higher poly sphere so the specular sans-normal map is smoother.

EDIT:

Or, if its going to be a single solid color, you could try selecting all of the faces of the sphere and doing a simple projection map. That way you'd have no seams - although this MAY make the normals appear even more wonky, since half of the shape would be projected backwards. And if you want more than 1 color on the diffuse, youd be out of luck.

#7 Create a new "constant normal" shader feature which hardcodes the normal as some arbitrary value in the shader. Then you don't have to worry about texture sampling issues at all, and save a bit of texture fillrate and VRAM to boot.

#8 Adam: Okay, I'll play around with the UVW Mapping in the places it is most noticeable. I should at least be able to move things around so it becomes least noticeable.

Alex: That actually is a really good idea, and I so wish we could implement that (and, seriously, I would be writing the pixel shader as I type this if I could use it in this project). However, we are using only Shadergen to maximize compatibility between computers. (Custom shaders can eventually lead into problems with different system configurations, however Shadergen spits them out with what will work on that system. So we use just Shadergen to help make sure it 'just works' on as many computers as possible).

-Dave C.
21-6 Productions

#9 Actually, the idea was to implement the constant normal as a new ShaderFeature in ShaderGen. It'd be a bit of work ( (1 day if you're familiar with ShaderGen, 2-3 days if you're not) but after that you'd be good to go.

#10 @Alex: Oh! I see what you're saying. Ok, now that is actually a very cool idea and we may have to look into it. Thanks for the suggestion, Alex!!

-Dave C.
21-6 Productions

#11 Dave if you have any huge issues hacking shadergen I've been doing a bunch of that. It is kind of a spaghetti mess, but some of the gotchas are:
1) 2 enums, shader feature and material feature, MF is a duplicate of SF. You can remove MF enum and change the references to SF.

2) This is the way the ShaderFeatureData stuff works:
-If the material has a feature, the flag is turned on in the processedXXXMaterial::determineFeatures call. (Or something like that)
-Turning on that flag means that when shadergen goes through the features it won't skip that shader feature. If the shader feature (the shader feature object which has the processPix/Vert) is NULL, that flag will NOT be set when it processes the other shader features in that pass. (Big gotcha) To get around that, if you just have a feature flag that you want other shader features to be able to detect, do something like this:

mFeatures[ GFXShaderFeatureData::DXTnm ] = new ShaderFeature;

ShaderFeature is a base class, and it won't do anything, or add anything to the finished shader, however if mFeatures[Feature] == NULL, that flag will not get set.

For example, the pasted code above is simply a flag to let ShaderGen know that this material is using a DXT compressed normal map (DXT1/5 swizzle trick) so when it goes to expand the normal, instead of just the normal *2.0 - 1.0 it needs to do:

bumpNorm.xy = tex2D( bumpMap, UV ).ag * 2.0 - 1.0;
bumpNorm.z = sqrt( 1.0 - bumpNorm.x * bumpNorm.x - bumpNorm.y - bumpNorm.y );

Once you figure out all the hoops you have to jump through, modifying and extending ShaderGen is a good tool.