Bump Map Issue

[forgeflow]

I've run into a texturing problem using LuxC4D. The issue I am having is that textures with bump maps are resulting in unpredictable results. Lux C4D is currently limited to UV mapping only, so if I use cube-mapping on a C4D object, I need to generate UV coordinates for the texture before exporting to lux. Performing this operation even on a simple sphere object displays the problem - on some faces the bump is outwards, on some faces the bump is inwards. I have a sample file that shows the issue:



The plane on the left shows the correct bump orientation. The sphere on the right shows the problem I am talking about - the bump appears to be outwards on the front and top facing sides, and inward on the right side. I am using LuxRender 0.6 Release, and the LuxC4D 0.06 exporter on Mac OS X 10.5.6, Cinema 4D 11.027. I attempted to reproduce the problem with 2 polygons - however, when I perform the "generate UV coordinates" step on a single poly, the bump comes out correctly. This makes me suspect that the issue is with the UV map, or the way that C4D is creating the UV map. Of course the bump should be rendered with respect to the direction of the surface normal, not the UV map. This makes me think the problem is with LuxRender itself, not the exporter.

Here are the lux files, plus the images maps, and the original C4D file:

http://planets.shacknet.nu/images/WeirdIssue.zip

[Heavily Tessellated]

Hi forgeflow.

I highly doubt it's Lux itself; while I don't know a single person who uses OS X nor Cinema 4D, I do know lots of people that run Blender on multiple linux systems. And I / we use procedural bumps with Lux every day... I'm sure if something as simple as an imagemap bump was broken that bad, the community would be howling.

You're seeing two things: One of them is that some of what you think is a reversed bump is due to a trick of the light, because of angle and global illumination. If you move the light source you'll see what I mean. Secondly is the map itself. Since the JPEG quality is locked at 93, I'm guessing you generated that texture in the free version of WW? Anyway, the texture. That black centerline one pixel wide that then transitions to a middle grey in one step? You're asking for trouble unless it's the most shallow bump possible. Drastic transitions do drastic bumps. But that's not the problem.

The problem? It's the UV mapping. It's a just bad example. I'll assume you know what you're doing and you cube-mapped a sphere and changed the UV scale to accentuate the errors, but without any pinned edges, constraints, or proper unwrapping, that, in and of itself, is causing the error you see. Let me show you a higher resolution version. (I disabled your wavy bump and widened the 1-pixel "trench" for effect.)

Look directly at the center longitudinal. Notice there's no bump? That's due to texture overlap. That's what's happening to what you call the "right side", not to mention you're mapping a gridded texture via cube projection onto a sphere.

Again, I know nothing about C4D, but I can't imagine it doesn't have a good set of UV tools. If it doesn't, you should download Blender, and export your C4D meshes into a format that preserves UV, such as Wavefront's OBJ format, and use the extremely nice UV tools in Blender, and re-import the OBJ.

Can you explain how you wish it would look? I could definitely help you there, as long as it makes sense when you translate it into C4D. Hopefully someone who knows that program or the exporter will pop by this thread. abstrax is definitely the one to talk to, and I see your other C4D threads, so hopefully you'll get a solution soon!

But I'm pretty sure this is one of those times where the computer is doing exactly what you're telling it to.

Good luck!

[abstrax]

Hi forgeflow.

I highly doubt it's Lux itself; while I don't know a single person who uses OS X nor Cinema 4D, I do know lots of people that run Blender on multiple linux systems. And I / we use procedural bumps with Lux every day... I'm sure if something as simple as an imagemap bump was broken that bad, the community would be howling.

You're seeing two things: One of them is that some of what you think is a reversed bump is due to a trick of the light, because of angle and global illumination. If you move the light source you'll see what I mean. Secondly is the map itself. Since the JPEG quality is locked at 93, I'm guessing you generated that texture in the free version of WW? Anyway, the texture. That black centerline one pixel wide that then transitions to a middle grey in one step? You're asking for trouble unless it's the most shallow bump possible. Drastic transitions do drastic bumps. But that's not the problem.

The problem? It's the UV mapping. It's a just bad example. I'll assume you know what you're doing and you cube-mapped a sphere and changed the UV scale to accentuate the errors, but without any pinned edges, constraints, or proper unwrapping, that, in and of itself, is causing the error you see. Let me show you a higher resolution version. (I disabled your wavy bump and widened the 1-pixel "trench" for effect.)

Look directly at the center longitudinal. Notice there's no bump? That's due to texture overlap. That's what's happening to what you call the "right side", not to mention you're mapping a gridded texture via cube projection onto a sphere.

Again, I know nothing about C4D, but I can't imagine it doesn't have a good set of UV tools. If it doesn't, you should download Blender, and export your C4D meshes into a format that preserves UV, such as Wavefront's OBJ format, and use the extremely nice UV tools in Blender, and re-import the OBJ.

Can you explain how you wish it would look? I could definitely help you there, as long as it makes sense when you translate it into C4D. Hopefully someone who knows that program or the exporter will pop by this thread. abstrax is definitely the one to talk to, and I see your other C4D threads, so hopefully you'll get a solution soon!

But I'm pretty sure this is one of those times where the computer is doing exactly what you're telling it to.

Good luck!

He talked already to me and I think it's might be an issue with Lux as I couldn't find any problems with the geometry and UV map. So I reckoned that he should ask in the Lux User Support Forum. I try to produce an even simpler example that shows this effect.

It's not the JPEG compression as the complete top quarter of the sphere is an inverted bump. And I think it's not the UV map as I checked a few polygons manually and they were fine.

But I will have another look at it later. Any ideas?

Cheers,
Marcus

[forgeflow]

Hi forgeflow.

I highly doubt it's Lux itself; while I don't know a single person who uses OS X nor Cinema 4D, I do know lots of people that run Blender on multiple linux systems. And I / we use procedural bumps with Lux every day... I'm sure if something as simple as an imagemap bump was broken that bad, the community would be howling.

You're seeing two things: One of them is that some of what you think is a reversed bump is due to a trick of the light, because of angle and global illumination.

The problem? It's the UV mapping. It's a just bad example. I'll assume you know what you're doing and you cube-mapped a sphere and changed the UV scale to accentuate the errors, but without any pinned edges, constraints, or proper unwrapping, that, in and of itself, is causing the error you see. Let me show you a higher resolution version. (I disabled your wavy bump and widened the 1-pixel "trench" for effect.)

Can you explain how you wish it would look? I could definitely help you there, as long as it makes sense when you translate it into C4D. Hopefully someone who knows that program or the exporter will pop by this thread. abstrax is definitely the one to talk to, and I see your other C4D threads, so hopefully you'll get a solution soon!

But I'm pretty sure this is one of those times where the computer is doing exactly what you're telling it to.

Good luck!

It's definitely not a trick of the light. Same scene, same lighting, in C4D:
http://planets.shacknet.nu/images/c4dweirdissue.jpg

Here's what I really am trying to do. I have a large building model that I can texture using procedural textures in Cinema4D and everything renders perfect. Of course, none of C4D's procedural textures translate to Lux, so I have to convert everything to a bitmap where I can. C4D has a perfectly reasonable cube-mapping option, that can take a flat repeating texture, and maps it front-back,top-bottom,left-right onto the very large and detailed building model, and all of the bumps come out the right way. Of course, Lux does not have a cube-mapping mode, so I was advised to convert the cube-mapping to UV mapping, which C4D certainly has the tools to do. If I take that exact same model and lighting and render it IN C4D, the bumps come out the right way on the model. It is only when I export the thing to Lux that it all goes south - Some bumps go in, some bumps go out, and its not predictable where on the model the bumps will be the wrong way around.

If I take the time to break the model down into constituent parts, and bake the texture to a properly created UV map, then yeah, Lux renders the bumps the right way around on the surface. So, no, I'm not trying to cube-map a sphere - I just grabbed the simplest example object that displays the problem. I could upload the actual model I really am trying to texture, but is a bit on the large size... Breaking the building down into digestible parts is tedious work, but right now, its my only option.

Re: the tight bump map: I do actually know what I am doing . The problems I am encountering are due to the fact that the C4D exporter to Lux is in the very early stages, so I am trying to work beyond it's limitations. C4D renders the bump like this:
http://planets.shacknet.nu/images/c4doutput.jpg

Lux, not so much:
http://planets.shacknet.nu/images/luxoutput.jpg You'll notice that on the rounded column on the right, the bump is light at the top, dark on the bottom, opposite to what it should be.

Finally, if I wanted to use Blender, then I would be... I'm not a fan of the program or how it works (I personally think the interface is awful). I imagine people using the exporters for 3D Max, and other programs feel the same way. I do not think this is an issue with the exporter per se. It MIGHT be an issue with how the UV map is being created in C4D, but on the other hand, C4D renders the bumps correctly, even if it's maps are "weird". I didn't go out of my way to create a bad UV map - I simply cube-mapped the texture, and told C4D to create UV coordinates for it, the same procedure I wanted to do with the actual building model. Having said that, I WILL let Blender have a go at producing a proper cube projection map of this particular object. If that's the cure, then so be it.

abstrax is the one who told me to post in here, as he couldn't sort out why it wasn't rendering properly

Ok, I had a look and couldn't figure out what's going wrong. Maybe it's because the UV coordinates are all out of the 0,0-1,1 interval, but I don't think it's the reason, as you can observe this problem even on a simple sphere object. So I think it's an issue with LuxRender. I guess the best thing to do is to reduce the scene to 2 polygons (1 with correct bump and 1 with incorrect bump), post it in the user support forum and let the devs figure it out.

Try as I might, I could not get the problem to appear with 1 polygon. While I agree that it's probably ultimately a problem with how C4D is producing the UV coordinates, my personal view is that Lux should be less sensitive to the issue...

[forgeflow]

I did some more testing. In these images there are two cubes - one 20 times the size of the other. On the left cube, the texture is tiled once. On the right, the texture is tiled 20 times. Logic would dictate that the two textures will appear to be the same - same scale relative to the viewer.

In C4D:


In Indigo:


In LuxRender:


I think it's a problem with Lux.

[Dade]

I think it's a problem with Lux.

Can you post the .lxs/.lxo/etc. files of this scene ?

[Dade]

I think it's a problem with Lux.

Can you post the .lxs/.lxo/etc. files of this scene ?

Ok, found in another post: viewtopic.php?f=29&t=2460&view=unread#p25819

[Dade]

Ok, found in another post: viewtopic.php?f=29&t=2460&view=unread#p25819

I repeated the test with Blender/LuxBlend and the out put looks correct:

I slightly modified the test scene to be more easy to "read" by using a simpler imagemap:

Again everything looks fine with LuxBlend. I attached the scene and the image map to this message, can you try to reproduce the above scene in C4D ? I could be something related to the way LuxC4D exporters the scene (i.e. difference in signs of U or V in C4D and Lux).

[Heavily Tessellated]

As with Dade, it works in Blender/LuxBlend, so I don't think it's Lux. Andd forgeflow, your latest example set pretty much examples it; Indigo renders it as you expect it to, which also lives and breathes on UVs.

So I'm immediately thinking it's got to be something to do with the exporter. It's scaling the UV coordinates. Again, I don't know C4D other than via Google, but is there a way to turn on UV coordinate viewing and grab a screenshot that? That way we'll know if the problem stems from the data that C4D is feeding to the exporter, or something flawed in the exporter itself. Or just wrap them with that imagemap Dade provided and render.

And/Or, if you don't mind, could you take that scene with the 1x and 20x cubes and export them and their UV coords (without conversion or scaling!) & their associated maps in OBJ format? Or any widely-accepted format that other apps can import that preserves UV. That way I can pull it into Blender or MeshLab or something; it will help narrow the search.

Great troubleshooting, by the way. Methodical. I know you're frustrated, but it will be solved.

[forgeflow]

Ok, here you go, simple as it can get:

Lux files:
http://planets.shacknet.nu/images/test2.zip

re: UV coordinates - looking at the .lxo file, both planes have the exact same UV coordinates. But here they are in .obj format:
http://planets.shacknet.nu/images/planes.obj.zip