Bump Map Issue

[abstrax]

Hi!

As LuxBlend is the reference exporter, but I'm too dumb to setup a scene similar to my C4D test scene, could someone please create a simple Blender scene with
- a simple point light
- a polygon sphere with a spherical UV map (smoothed, i.e. with vertex normals)

It is not exactly what you have asked for, but something close to it:

UV_sphere_scene.tar.bz2

Scene contains:
- a point light
- a smooth polygon sphere with custom UV-mapping which looks close to spherical
- material of the sphere is glossy.

Thanks a lot

[abstrax]

As LuxBlend is the reference exporter, but I'm too dumb to setup a scene similar to my C4D test scene, could someone please create a simple Blender scene with
- a simple point light
- a polygon sphere with a spherical UV map (smoothed, i.e. with vertex normals)
- a matte material with 80% grey as diffuse colour and this file as bump map:

Too dumb, ya right! Too lazy?

Anyway, here it is, exactly as requested minus my poor approximation of your camera FoV and viewing angle of the sphere. You did not specify scale, so the sphere is 1m and bump depth is 0.01m, with U 1.0 / V -1.0 / UΔ 0.0 / VΔ 0.0 - or if you'd rather see this than have me explain it I've attached a screenshot of the entire process. Hope this helps you figure out why your normals are inverting on export.
---
edit: helps to actually attach said .blend, doesn't it? <sigh> "The extension blend is not allowed." - what monkey set phpBB to disallow .blends?!

The problem is I don't know nothing 'bout Blender and after fiddling around for mor than an hour and not getting anywhere reasonable, I gave up. At the moment I don't have time to learn Blender.

Thanks a lot for your help

Cheers,
Marcus

[abstrax]

After more than 1 day of fighting with Lux, finally some good news: I found a workaround for the bump problem. I call it "workaround", because I think it's a LuxRender problem.

The workaround is to invert the V coordinates (i.e. vCoord=1-vCoord) of the poygon object and to invert the V scale (i.e. vScale=-vScale) of the UV mapping. To me it doesn't make much sense, as the bump shading should be independent of the UV direction ...

Anyway, this is what you get, when the bump is correct:

Cheers,
Marcus

[Heavily Tessellated]

Hmm, V is always negative, for instance in LuxBlend if I wanted to tile same texture 4x as dense it would go on as U:base+4 V:base-4, that's just the way it's done, in every app. The Vscale thing, that's definitely funky; so that's the only way to get white to be "up" and black to be "down" ?? Interesting. Also, are you working with a version incorporating that delta patch that Dade made (minus the Bidir integrator), if not, can you check out the 06x branch from Mercurial and build it?

[Dade]

invert the V scale (i.e. vScale=-vScale) of the UV mapping.

This is exactly what LuxBlend does.

To me it doesn't make much sense, as the bump shading should be independent of the UV direction ...

Isn't it is only a matter of right-hand/left-hand coordinate systems ? If C4D uses different system from Lux, you have to do the translation in the exporter but I would not define that a work around.

[abstrax]

invert the V scale (i.e. vScale=-vScale) of the UV mapping.

This is exactly what LuxBlend does.

To me it doesn't make much sense, as the bump shading should be independent of the UV direction ...

Isn't it is only a matter of right-hand/left-hand coordinate systems ? If C4D uses different system from Lux, you have to do the translation in the exporter but I would not define that a work around.

First I thought the same, but no I don't think there should be any conversion thing necessary, except I'm missing something here. A UV coordinate is just defining a location of a vertex in texture space, right? And as long as this position in texture space means the same location in the texture bitmap, it should be fine, shouldn't it? And that's the case here: If I take UV coordinates (0,0) or (1,0) or (1,1) or (0,1) it means the same bitmap location in C4D as well as Lux. But unfortunately the shading goes wrong. So what do I have to do: I have to break the UV coordinates by inverting V and fix it again by inverting V scale. Does't sound right to me, does it?

Cheers,
Marcus

[Dade]

First I thought the same, but no I don't think there should be any conversion thing necessary, except I'm missing something here. A UV coordinate is just defining a location of a vertex in texture space, right? And as long as this position in texture space means the same location in the texture bitmap, it should be fine, shouldn't it? And that's the case here: If I take UV coordinates (0,0) or (1,0) or (1,1) or (0,1) it means the same bitmap location in C4D as well as Lux. But unfortunately the shading goes wrong. So what do I have to do: I have to break the UV coordinates by inverting V and fix it again by inverting V scale. Does't sound right to me, does it?

Abstrax, what about vertex order ? I mean, are you exporting all vertices in a clock-wise or counter-clock wise order ?

Look, this is a rendering done with 2 triangles exported with vertices in the same order:

While if I change the order of the vertex indices of one of the 2 triangles:

See ? The "sign" of the bumpmapping is inverted

[tinus]

Isn't changing the order of the vertices the same as flipping the normal? It would be logical for the bump map to work the other way then, since for one of the triangles you're looking at the front of the face and for the other you're looking at the back.

[Dade]

Isn't changing the order of the vertices the same as flipping the normal? It would be logical for the bump map to work the other way then, since for one of the triangles you're looking at the front of the face and for the other you're looking at the back.

Yes, I changed the order of indices of the right/lower triangle and it is the one to look up side down (compare the first image with the second). Were you assuming I changed the order of the left/upper

[tinus]

No, I was assuming you did not understand why on one half the bump map pushes the surface up while on the other half it pushes the surface down.

Surely the C4D exporter can't be messing up the normals like that if you define them correctly while modeling? It would show up in a lot of situations (for example, glass).