(click image for a larger version)

Here is a rather drastic illustration of an effect BB mentioned a while ago in this thread. I came across this low-light situation by pure accident - a spotlight pointing astray - and rather liked it. But as you see in the image on the left, which was rendered from an unaltered export file, Lux can have a hard time shading a relatively coarse mesh like Antonia's correctly. (Please ignore that that side is also grainier. I just didn't have the patience to let it render 3 hours like the right side.)

The image on the right was rendered after adding the following two lines to every shape definition in the .lxo file:

  "integer
nsubdivlevels" [2]<br></br>
  "bool dmnormalsmooth"
["true"]<br></br>

This tells Lux to subdivide the mesh twice (each step turning every triangle into four smaller ones) and to interpolate the normals for the subdivided mesh. This gets rid of the nasty artifacts at the terminators, but now we have a new problem. To make the texture mapping work correctly, the exporter has to cut the mesh apart at texture seams. As a consequence, Lux takes these seams as mesh boundaries and does not interpolate normals across them. Also, where the cutting of the mesh creates a corner, the subdivision process results in a small gap in the mesh which is visible as a black dot.

Obviously, I am hoping that we'll soon be able to use per-polygon UV coordinates in Lux (or the slightly modified Lux-derivative bagginsbill talked about), which will eliminate the latter problem and enable us to have Lux subdivide the mesh for us. But until that happens, I'm considering adding an optional subdivision step to the exporter. A subdivided mesh will obviously result in considerably longer processing times, larger output files and also more work for Lux when importing the mesh. So it would not make much sense to subdivide by default. It really depends on the scene, and maybe even the object that's being exported.

-- I'm not mad at you, just Westphalian.