Normal maps vs bump maps

[Lord Crc]

the normal map defines an exact normal orientation, so you can't apply any kind of weight to it contrary to a bump map

The normal map is used to implicitly reconstruct the height function, and that height function can of course be scaled like any other. However it would then be a relative scale. If people find this confusing we could of course drop the scaling field, and let advanced users use the scale texture to perform this function.

[J the Ninja]

As for applying them - I would have thought an additive process as jeanphi suggested - ie, first apply the normal map to get the shading geometry, then apply the bump map to that would work?

Why would you expect differently from combining a normal map and a height map, than combining two height maps?

That ISN'T any different to two height maps combined with the multi mix texture. Right?

[jeanphi]

Why do you reconstruct a height function instead of just applying the normal transform?

Drifting a bit off-topic here but:

Because then we'd have to have two different Bump() methods, one which takes normal maps and one which takes bump maps. This way Bump() and everything else bump related stays exactly the same, and uses the GetDuv() just as with any other heightmap. Only thing new is the "normalmap" texture. I feel that this is a quite elegant implementation as it avoids special-casing in the core.

And personally I think it's very nice that you can mix normal maps with height maps in the same manner as you can mix two height maps. Otherwise this would be non-trivial.

edit: oh, and I don't explicitly reconstruct the height function h(u,v), only implicitly. I recover the derivatives dh/du and dh/dv directly. However if the height function is h(u,v) = s*f(u,v) then of course the derivatives are just dh/du = s*df/du etc, which is exactly what the "scale" texture does in it's GetDuv(). Thus this works the same for a regular height map and a normal map, and so does the mix/multimix textures etc.

[Lord Crc]

That ISN'T any different to two height maps combined with the multi mix texture. Right?

Not exactly sure what you're stating here but: currently, if you use mix or multimix to combine a normal map and a height map, then this works exactly the same as if you combine two height maps the same way. The only difference is the scale values involved if you use multimix.

[jeanphi]

Hi,

Ok, the current implementation has some nice side effects indeed.
Note: it seems someone edited my previous post instead of replying to it

Jeanphi

[Lord Crc]

Ok, the current implementation has some nice side effects indeed.
Note: it seems someone edited my previous post instead of replying to it

Argh that must have been me, big time sorry I really dislike how that edit button is so close to quote, and with no safeguards.

So, to sum it all up, the consensus is to keep the "bump mapping" input as is, and add a single normal mapping texture-slot only? The exporter will then export a multi mix with "bump scale" and "1" as weights, respectively.

Any advanced users can then do what they please using the scale etc textures.

[J the Ninja]

So I've gotten to work implementing this, here's what I just pushed:

Screen Shot 2011-12-20 at 12.49.16 AM.png (14.75 KiB) Viewed 489 times

Any imagemap or normalmap texture assigned to the normal map slot will get exported as a normalmap tex. It and the bump map texture will be stacked via the multi mix texture.

At the moment, the UI is a little bit awkward. I left the bump map controls as the existing controls to maintain backward compatibility with old scenes. We could instead make TF_bumpmap a tex-only param and add a separate bump height field. This makes the panel a bit neater aesthetically, and also gets rid of the pointless T and M buttons. (That M button on bump map literally does nothing now. The scale-tex is still exported, but is never called by any parameter, the multi-mix tex that has the bump height as its channel weight is used instead). The nicer UI would look something like this, but comes at the cost of breaking bump height in existing scenes:

Screen Shot 2011-12-20 at 12.56.59 AM.png (14.21 KiB) Viewed 489 times

Finally, this won't work with the blender-image texture at the moment, and after a bit I figured out why. The code is a modified version of the code that runs the diffuse/reflection alpha feature, and it turns out that cannot handle blenders image tex either. (the main reason is that the filename parameter is located somewhere else). I'll see what I can do about this tomorrow. It's now 1AM here though, and I should've been in bed awhile ago as it is.

[paco]

Nice work J

I think the layout might be confusing to new users - it wouldn't be obvious to me visually that the bump height parameter doesn't affect the normal map. Might just be me though. My suggestion would be to put the bump scale beside the slot rather than above it?

[Abel]

Nice work J

+1

I think the layout might be confusing to new users - it wouldn't be obvious to me visually that the bump height parameter doesn't affect the normal map. Might just be me though. My suggestion would be to put the bump scale beside the slot rather than above it?

When it comes to the interface, I'd find it logical to have the height parameter being defined later (after or under) than the texture; without having defined the texture there is no point in defining a scale.

One possible solution would be:

Material type: matte
Interior
Exterior
Normal map
Bump map
Bump map scale

However, somehow in the back of my head something is telling me that bump should go before normal as it is probably being used more and learned earlier. If others share that feeling, just changing the "Bump scale" to "Bump map scale" might help make the situation a bit less ambiguous.

[J the Ninja]

Yeah, I debated a bit where to place things. I originally had bump height in the middle with bump map on top, which was even more confusing, IMO. I was leaning towards the arrangement abel suggested with normal map on top.

Btw, any thoughts on replacing the bump height parameter? Do people think that is worth breaking height settings for old scenes?


Oh, and finally, I pushed a fix for using blender's image tex with this. I applied the same fix to using blender image with alpha transparency in diffuse/reflection mode, both of them work now.