bump map + normal_smoothing?

[CTZn]

Actually I'm protesting against normals and UVs issues ! There is an implicit "thanks for Indigo as it is" in my statement

[OnoSendai]

I'm doing a bit of coding on related issues, and I think this is a pretty fundamental problem with bump mapping / shading normals.
The problem is is that the observer expects some direct illumination on the bump-mapped triangles pointing away from the light source. However, this is impossible, as the triangle itself occludes the light.

As I've said before, bump mapping is a nasty hack that should be avoided anyway, this is just another piece of evidence in favour of my argument.

[Deus]

Yeah you are right Ono. Why dont you make displacement mapping work at the memory cost of a bump?

[alex22]

Reliefmapping, conemapping or steep parallax mapping would be cool. The problem of it being 2D when seen from the side should be solveable if you map the texture to a cube rather than a plane. (hope you understand what I mean)

[PureSpider]

World domination would also be cool...
Keep it real, guys!

[alex22]

I had a pdf of different Displacmentmapping algorithms on my PC. It is ment for GPU, but it should applie to a CPU as well.

[Deus]

Its definately unrealistic... lol

Parallax mapping etc is for graphics cards and not for raytracing

[BbB]

Suv: Yes, I meant unbiased.

Ono: Happy to ditch bump mapping if there's a fast, practical, economical alternative... But there isn't really, is there?

[CTZn]

The problem is is that the observer expects some direct illumination on the bump-mapped triangles pointing away from the light source. However, this is impossible, as the triangle itself occludes the light.

Ok I understand that. Let's "theorethoricalize" on that issue, free diving:

The height of bump is known, it's the <b> parameter (basically, as <a> & <c> can be involved). One could test, for each triangle pointing away from light and sharing a vertex with a lighted triangle, if the side face (sharing 2 vertices with lighted neighbour) issued by the extrusion of the dark tri along its normal by <b>, is lighted. If yes, due to the bump effect the whole tri will be considered as under light.

edit: of course the new state of the tri doesn't allow him to propagate that property of running the test to other tris pointing away the light source, or that'll defeat the point. Hopefully there are no others caveats, you say

edit 2: Or maybe one would take the average normal of:

1_ the tri pointing away light, sharing vtx with 2_
and
2_ the next tri, pointing to the light and sharing vtx with 1_

instead of just the normal of 1_,

Basically I mean using vertices normals instead of faces normals.

Because logically if the normal at vertex has positive facing ratio with light there is no reason why the face should be considered in the dark

[v_mulligan]

I'm doing a bit of coding on related issues, and I think this is a pretty fundamental problem with bump mapping / shading normals.
The problem is is that the observer expects some direct illumination on the bump-mapped triangles pointing away from the light source. However, this is impossible, as the triangle itself occludes the light.

That can't be the only thing going wrong in the test images posted. If it were, then the teapot lacking a bump map would show nearly identical shading artefacts. Most places on the surface, the normal direction is unchanged with that brick bump map.

As I've said before, bump mapping is a nasty hack that should be avoided anyway, this is just another piece of evidence in favour of my argument.

Yes, if artists would only constrain themselves to smooth surfaces, everything would be peachy. Unfortunately, we do occasionally want to render bumpy surfaces, and since Indigo's displacement mapping isn't working (see this thread) and displacement mapping is a pretty inefficient way of doing fine details in any case, Indigo needs functional bump maps if it's going to compete. The "you don't need that feature" argument really doesn't fly.

[v_mulligan]

I did some bump tests, which I'll post soon. Even on triangles facing towards light sources, there's no normal smoothing if they're bump mapped. The occlusion issue can't be the only thing going wrong, as I stated in my previous post.

As for the occlusion issue, THAT'S one issue that I wouldn't bother addressing. It's a limitation of ray-tracers (and renderers that use related algorithms, including unbiased renderers). Anyone with experience with bump maps knows that they should be used subtly, for fine details -- not for anything that would appear to distort the surface so much that backside triangles ought to receive lighting.

In the case of the present problem, though, no matter how subtle the bump map is, it still affects normal smoothing.

[CTZn]

v_mulligan, you use blendigo ? external obj ?

[v_mulligan]

I've been exporting using the Softimage XSI exporter. Everything is in the same IGS file (well, except for the bump/displacement map). Unless the UV coordinates on the mesh are what you're wondering about, I don't think the exporter is the issue. I've been editing the file manually to add bump, subdivision, and/or displacement.

[v_mulligan]

Here's a bump-mapped cylinder with normal smoothing ON and subdivision OFF. Note that although all triangles are facing the light source, there is a sharp change in surface shading from one facet to the next. The bump map seems to be using the geometric normals rather than the smoothed normals.

[CTZn]

The bump map seems to be using the geometric normals rather than the smoothed normals.

quote ! No matter what <merge_vertices_with_same_pos_and_normal> is set to.