LuxC4D 0.06

[abstrax]

Yes, please try it with different bump strength. What you might see here is that the bump strength is too high on Lux side.

Trying that right now... took it from 100% down to 5%. The bump looks better on the cubical object, but is still inverted on the cylindrical object. The annoying thing is that it is not the same all over the object - in some places it is correct, and not in others. It's quite maddening.

Can you please send me the scene via PM - so that I can check, what's going on?

Thanks,
Marcus

[abstrax]

I had hoped to have 0.06c out already, but I'm still having problems to launch LuxRender with a scene file on MacOS from C4D R9.x and R10.x. I'm working on it and still have a few things to try.

hey abstrax,

http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044654269&id=1043284392

check out option 3

(edit: it also allows you to launch multiple instances of an application at the same time on OSX, which is quite nice)

Thanks for the link. That's what I wanted to try out next, but I wasn't sure if POSIX calls were possible in XCode. Well, obviously they are. That's good to know.

The only problem I have now with R9.6 is the conversion between HFS-style and POSIX-style paths. My intermediate solution creates a launch script which then launches LuxRender, because interestingly when I call GeExecuteProgram(), C4D launches LuxRender, but LuxRender doesn't open the scene file (when I try the same with TextEdit, it works...), but when I do the same with a shell script, it works. This stuff is quite hairy on Mac OS and C4D changed significantly between R9.x and R11.x ... so lot's of fun.

Cheers,
Marcus

[forgeflow]

I've figured out the UV mapping troubles. The trick is to open up C4D's UV editor and change the projection type to "box". That seems to sort out the UV mapping issues. Simple cube-mapping doesn't work - makes UVs outside the coordinates that LuxRender expects to find them, and the cube and cube2 projection mappings introduces distortion in the UVs that make them difficult to resolve.

I think I have something "sort of - kind of" figured out with the bump mapping issue. Looking at the texture setup in LuxBlend, it seems there are two components to bump maps - bump scale, and gain. Bump scale seems to control the size of the bump features, and gain gives the strength of the bump effect. LuxC4D is translating the bump strength to bump scale, but not providing any gain. As the strength of the bump effect seems to be tied directly the scale of the object (unlike C4D) there seems to be no easy way of controlling the effect, currently, other than directly editing the .lxm file and guessing different values. Since I want to see more of a definite bump effect, I keep turning up the bump strength, but all this does is spread the bump effect out wider and wider (kind of what C4D does with the "delta" value in procedural textures) rather than doing anything meaningful with the DEPTH of the bump effect, to the point where the hills and grooves are out of place with each other, giving the the appearance that the bumps are facing the wrong way.

So.. I guess what I am asking for is some kind of control over bumpiness in LuxC4D, or at least have it write out some intelligent default values for gain and scale.

My trouble right now is that I have the object UV mapped correctly (confirmed with a colored UV checkerboard pattern), but the scale of the bump map effect that I am trying to apply simply is too large for Lux - I can put same texture on a simple cube object and it bumps just fine, but the building object shows nothing until I turn the gain up to 64, and then it it apparent that the scale is WAY off - the bump is 20x wider than it should be, and it's proving impossible to find the right values to plug in there to make it work. I'm about to give up on this as unworkable at this point. This is far too much time and energy spent on applying what should be a simple cube-mapped repeating texture pattern to a surface.

[abstrax]

I think I have something sort of - kind of figured out with the bump mapping issue. Looking at the texture setup in LuxBlend, it seems there are two components to bump maps - bump scale, and gain. Bump scale seems to control the size of the bump features, and gain gives the strength of the bump effect. LuxC4D is translating the bump strength to bump scale, but not providing any gain. As the strength of the bump effect seems to be tied directly the scale of the object (unlike C4D) there seems to be no easy way of controlling the effect, currently, other than directly editing the .lxm file and guessing different values. Since I want to see more of a definite bump effect, I keep turning up the bump strength, but all this does is spread the bump effect out wider and wider (kind of what C4D does with the "delta" value in procedural textures) rather than doing anything meaningful with the DEPTH of the bump effect, to the point where the hills and grooves are out of place with each other, giving the the appearance that the bumps are facing the wrong way.

So.. I guess what I am asking for is some kind of control over bumpiness in LuxC4D, or at least have it write out some intelligent default values for gain and scale.

The gain value is a parameter of a texture in LuxBlend and scales the color/brightness values of texture by multiplying each other. The bump scale is just another scale value/multiplicator which is applied on top of that -> it should make no difference if you set the bump scale to 1.0 and the gain to 0.1 or the other way around.

If not, I must have misunderstood something.

Cheers,
Marcus

PS: I will investigate the bump problem tonight, when I'm back home. Let's see where I get.

[forgeflow]

The gain value is a parameter of a texture in LuxBlend and scales the color/brightness values of texture by multiplying each other. The bump scale is just another scale value/multiplicator which is applied on top of that -> it should make no difference if you set the bump scale to 1.0 and the gain to 0.1 or the other way around.

If not, I must have misunderstood something.

Cheers,
Marcus

PS: I will investigate the bump problem tonight, when I'm back home. Let's see where I get.

I guess I don't understand why two objects, textured with the same texture, at roughly the same visual scale, get rendered completely differently with regards to the effect of the bump channel.

Did a test:
One texture, two objects. The object on the left is 200 cm per side, the object on the right is 4000 cm per side. The object on the left is textured with 1 tile, the one on the right has 20 tiles. Logic would dictate that since the textures are the same size visually, that the bump would also be the same, visually.

This is true in C4D:
http://planets.shacknet.nu/images/c4dbumptest.jpg

This is not true in Lux:
http://planets.shacknet.nu/images/luxbumptest.jpg - the bump on the tiled texture is spread out and indistinct. WTF.

Here are the files:
http://planets.shacknet.nu/images/bumptest.zip

[abstrax]

I guess I don't understand why two objects, textured with the same texture, at roughly the same visual scale, get rendered completely differently with regards to the effect of the bump channel.

Do you mean the positive/negative bump effect of two adjacent polygons? Well, that's the tricky question I can't answer at the moment. I have to do some more experiments to give a final conclusion. I couldn't find any problems with UV export yet and the UVs as far as I can see. Just use this test texture http://bgdm.katorlegaz.com/lscm_tute/Tute_Images/UV.jpg and you can immediately see, whether the UV coords are correct or not.

I hope I can give a better answer tonight.

Cheers,
Marcus

[forgeflow]

I guess I don't understand why two objects, textured with the same texture, at roughly the same visual scale, get rendered completely differently with regards to the effect of the bump channel.

Do you mean the positive/negative bump effect of two adjacent polygons? Well, that's the tricky question I can't answer at the moment. I have to do some more experiments to give a final conclusion. I couldn't find any problems with UV export yet and the UVs as far as I can see. Just use this test texture http://bgdm.katorlegaz.com/lscm_tute/Tute_Images/UV.jpg and you can immediately see, whether the UV coords are correct or not.

I hope I can give a better answer tonight.

Cheers,
Marcus

You replied before I edited my post - my bad . Have a look up, I posted an example of what I'm running into.

[forgeflow]

I assume that what Dade posted about the "float bumpmapsampledistance" [0.00001] made some kind of sense. Anxiously awaiting the day where I don't have to do a bunch of editing of .lxo and .lxm files in BBEdit after every export.

Edit: I'm discovering the importance of light groups. Couple of questions:
1) Is it possible to automatically put the Sun in it's own light group when you add the light tag to the Sun object
2) Can the sun and the sky be in separate light groups or are they always tied to each other?

Yet another Edit:
I have a number of hanging lamps in this scene - and I am using the shape of the lamp globe as the shape of the Lux Area Light (which works just fine btw.). However, all of the lamps are instances of the one set of geometry in C4D. However, when I export this to Lux, each instance repeats the entire geometry setup of the one light object. Does Lux support instancing, and if so, then the exporter should export a C4D instance as a Lux instance, yes?

[abstrax]

I assume that what Dade posted about the "float bumpmapsampledistance" [0.00001] made some kind of sense. Anxiously awaiting the day where I don't have to do a bunch of editing of .lxo and .lxm files in BBEdit after every export.

I'm working on it. I hope I have sorted the last problems this week end. If not I will release a preliminary version (without the support of C4D R9.6).

Edit: I'm discovering the importance of light groups. Couple of questions:
1) Is it possible to automatically put the Sun in it's own light group when you add the light tag to the Sun object
2) Can the sun and the sky be in separate light groups or are they always tied to each other?

1) You can create a light group by entering a light group name into the light tag. This will not happen automatically. If you want so, I can make it automatical.
2) If you create a light of the type "Sun + Sky", you can't split them into two light groups. You would have to create two lights then: One for the sky using light type "Sky" and one for the sun using light type "Sun". Usually the relative brightness between sun and sky shouldn't be changed, as they are coupled to create realistic results.

Yet another Edit:
I have a number of hanging lamps in this scene - and I am using the shape of the lamp globe as the shape of the Lux Area Light (which works just fine btw.). However, all of the lamps are instances of the one set of geometry in C4D. However, when I export this to Lux, each instance repeats the entire geometry setup of the one light object. Does Lux support instancing, and if so, then the exporter should export a C4D instance as a Lux instance, yes?

Instancing is not supported yet in LuxC4D

Cheers,
Marcus

[forgeflow]

1) You can create a light group by entering a light group name into the light tag. This will not happen automatically. If you want so, I can make it automatical.
2) If you create a light of the type "Sun + Sky", you can't split them into two light groups. You would have to create two lights then: One for the sky using light type "Sky" and one for the sun using light type "Sun". Usually the relative brightness between sun and sky shouldn't be changed, as they are coupled to create realistic results.

Artistic license and all that. Have to do similar tricks in photographing VR Tours - you have to expose the room and the windows differently, and do exposure blending to get a "pleasing" result. It might not be real, but it beats blown out windows. I'll play around with this. Since I've gotten past the bump map thing I'm loving Lux again, so the project is progressing.