Mesh : What about independant normal orientation ?

[Rom1]

Ok,

I really need this implemented so ... I will try to do it myself

If I understand quite :

I need to define interior and exterior medium for all my mesh

I need to store the medium of the ray

When I reach a shape, I need to compare the medium to decide if i am outward or inward.

and determine the normal.

true ?


Well .. where is the best location for the "compare medium" part ?

[paco]

Are you able to post an example mesh? Something small and readable by blender (for me at least) would be ideal.

[Rom1]

Yes

I have attached an example with two faces

the two faces are from the same object, but the two faces are not well oriented.

(one of the faces have the normals oriented inward)

Glace_m.stl

Glace_m.stl : two faces oriented in the same direction, one of them would not respect the "normal exterior" requirement

(94.42 KiB) Downloaded 5 times

[paco]

Hmm.... have posted a pic below.

Firstly all the triangles don't seem to share verts - so lots of dupicates - is that a property of the STL format, a property of your data, or something I screwed up?

Secondly, if you removed the duplicate verts and had a true mesh - the problem is that you've got the wrong normals to allow you to apply a single material (like glass say) and have it work on the object. However in the glass example could you not create another medium or something that is the opposite of the original one (ie, outside <-> inside) and apply that to the incorrect face?

Or were you hoping to avoid that altogether and get something more automated?

I must admit it would seem to me at this point that lux probably isn't the place for that to happen - might need to have some intermediate process - like a blender script?

[jeanphi]

Hi,

The meshes Rom1 is dealing with are quite complex so he needs an automated process, Lux has to be adapted to this special need, that's the whole point of this thread. Even a Blender script will not fit because some faces are disjoint so computing a surface orientation won't be possible.
It shouldn't be that difficult though, you just need to check the previous medium and tweak the normal accordingly.

Jeanphi

[Rom1]

Hi,

First Jean-phi point our problem : the surfaces are more complex, we got more than 16M triangles on some of them. The less we use intermediate tools, the more we speed up the global process.

That's why we should be happy to have luxrender independent of the normal orientation.

However you are true, we have two option for this kind : export the two mesh and invert one of them, then use the glass 2 material.
Export each mesh and use two material, one have been "inverted"

But this two option are only available when you have the two group of normal separated, in our case we have only one mesh.

In more complex products we can obtain more than thirty groups of normals. Currently I need to invert each of them one by one.

We can't do this with an automatic process, because the cases are too complexe, I tried few tools with automatic option and I was not able to find a good solution.

So we need to have a luxrender strategy that would correct the normal orientation.

I think I'm not able to write that code but I'm looking for a "well-meaning soul" that would help me.

One more question : What is "media precedence" ?

[jeanphi]

One more question : What is "media precedence" ?

It's a system usefull for complex setups wit multiple interfaces, like a glass of water. Currently you need to separately model all 3 interfaces (glass/air, glass/liquid, liquid/air). With media precedence, you would model the glass, model the liquid so that it goes slightly into the glass, and tell that the liquid has a lower precedence than the glass. When hitting the liquid inside the glass, Lux would treat that as a null material because the liquid precedence is lower, and when reaching the glass, Lux would remember that the ray is inside the liquid mesh and would use the liquid properties as exterior.

Jeanphi

[paco]

Hmm... I'm no expert on the media code so i'll leave that bit to jeanphi - certainly appears like it is simpler than the approach i'd suggest:

(it's based on the ray casting algorithm - http://en.wikipedia.org/wiki/Point_in_polygon)

1) Make the assumption that all volumes are modeled, and form closed shapes - ignore small holes for now and assume there are no surfaces that aren't part of a volume.
2) For each triangle choose a direction (?tri normal) and extend to the bounding box in forward/backward direction.
3) Calculate ALL intersections along those rays
4) Take the first and last tris to require a normal pointing outwards (ie, in same direction as ray) - adjust as necessary and mark as checked.
5) Working towards the original tri adjust the normals so you get an out/in/out/in etc sequence.
6) If there is an error - ie, wrong number of intersections or you find a tri already marked which has an inconsistent normal - add both tris back to list to be checked (but try different ray this time)
7) Keep going until all tris are checked

In theory for a closed mesh this should work. Might take time though.... and could indeed be implemented as a python script in blender or somewhere external to luxrender - from memory there is an intersect method available in the blender python api.

Still, if you do it externally it would only need to be done once and then you could play with materials as required. Also to speed things up i'd consider removing duplicates initially and then selecting linked vertices into a list of surfaces rather than individual triangles - but not sure if your mesh configuration would allow this to work.

[Seabass]

Hello there,

Let me first introduce myself. I'm Seabass and I currently work for Rom1's project.
I am now in charge of the normal orientation process and have some ideas on how to deal with it.

Before that, let me remind you the problem we face.
Since we deal with cad surfaces that are regularly edited by different designers, the object exported does not have its surfaces normals defined homogeneously.
The general idea is to modify LuxRender's core engine to make it 'normal independent'.

Rom1 and I have thought about different solutions and we finally came with one that seems to be interesting.
Since our surfaces are quite complex, we decided to keep track of the material one ray is actually going through.
As we know the material the ray is starting from, the idea is to check the material faced when it intersects a surface.
So that when the two materials are not the same, we "flip" the surface normal.

We are now thinking about the best way to keep the material data into the ray structure and the best way to compare two materials (since materials do not have the same parameters set).
Lately, two ideas came out. We can compare two strings containing the ParamSet data together, or compare the Paramsets themselves.

I would like to get some of your opinions on this, since it could be an interesting "plug-in" for LuxRender future versions.

Thank you in advance.

Seabass

[jeanphi]

Hi,

Actually all computations happen in the BSDF, so basically you could just add a member to the BSDF class to swap the normals and do the swapping in the volume integrators: you have access to the required information there, and there's already code to update the volume data in there in case it is missing, it would fit quite naturally.

Jeanphi