Inconsistent shading normals, the sequel

[pciccone]

Sorry to re-open this but I'm trying to find out if there is a solution for this or if there is an issue with the check of normals in Lux. I isolated a model, a human head, that is triggering the "inconsistent shading normals" message in Lux 0.7 and I can't seem to be able to get rid of the problem, no matter what I do.
I loaded the head in Blender 2.49, recalculated the normals outside, exported the model with LuxBlend and I still see the message. Shouldn't the normals be OK after the recalculation?

TIA

[SATtva]

I noticed that in some rare cases tightly placed vertices and stretched out polys lead to false alarms of inconsistent normals. When I'm confident in model correctness I tend to ignore such warnings.

[pciccone]

That's reassuring. DAZ Studio models can have quite a bit of very small details, the inside of the nostril or the eyelashes and the space there is very, very tight with some of them intersecting. I wanted to double check before trying to re-calculate the normals on my own instead of simply getting them from Studio.
Maybe this is something that could be looked into at some point, or the added precision would slow down Lux?

Thanks.

[jeanphi]

Hi,

The issue right now is that in LuxRender objects are not named, so there's no way to tell which object is the culprit. I think we should try to overcome this limitation as given the object name and the face number an exporter should be able to select the corresponding face in the host application.

Jeanphi

[pciccone]

Well, technically we have the ObjectBegin command, the main problem is that a lot of exporters use the AttributeBegin command instead. It would be fairly simple to move from one to the other except that the way Lux orders the geometry in the file is often causing divisions where there were none in the original model. For example a "head" model is one single "piece" but divided in different material "zones": skin, lips, eyelashes etc. Each groups would be called "head".
Of course we could generate object names such as "head_lips" and that would solve the problem.
And since we are talking about object names I had some thinking about instancing and I hope you can clarify a couple of things. Human models are very high in poly count. DAZ's V4 is about 70,000 polys, naked. Add clothing and you can easily double that. A scene with single instance of that model is several megabytes of .lxo file. Possibly in the range of 30-60MB.
I like to use instancing for scene where there are multiples of the same model but the issue is with morphing. The same mesh can be used for several, completely different, shapes. Right now I output the morphed/transformed geometry for every model. Is there a way of using instancing in Lux and maintain the morphs?
If no, would it be worth thinking about it?

[jeanphi]

Hi,

The issue with using ObjectBegin is that it forces an instance which has a speed penalty over a regular shape, but yes, that's a possible way of doing it.
Regarding morphing, LuxRender has no deformation operator, so as long as your morphing consistent only of translation, scaling, rotation applied uniformly to the whole base object, then yes it's possible to use instancing, otherwise it's not.

Jeanphi

[pciccone]

Regarding morphing, LuxRender has no deformation operator, so as long as your morphing consistent only of translation, scaling, rotation applied uniformly to the whole base object, then yes it's possible to use instancing, otherwise it's not.

Yes, I know, but I was thinking that we could add a "Morph" command to be used in place of the "Shape" command. When used in conjunction with the object instancing Morph would list an array of points corresponding to the transform of each vertex listed in the original shape array. The benefit of this would be to save a lot of space for the normals and uv maps, which take a lot of space and would not be required to be re-exported. Just an idea.

So, something like:

ObjectInstanceMorphedBegin "head"
NamedMaterial "mymaterial"
Morph "point P" [
.
.
.

]
ObjectInstaceMorphedEnd