-1

i am new to 3D math, but i am facing a problem that when i am importing a model to CAD program - (single sided light/ open scene graph) - there are a lot of faces from meshs, Black !

When i flip the normal manually for each of the faces i got the correct material and texture.

my question is, if i know vertices table and normals table for every mesh in the model, can i write an algorithm that will correct all wrong normal direction automatically, i mean it must detect the wrong normals without any help form users and correct them.

i thought about an idea that needs image processing, i know nothing about image processing, so if you can help with from where i should start to achieve this :

first i will assume every blacked face is a wrong normal.

second i will direct a light form the camera to the mesh, and if are all the pixels in black then flip the normal.

and do this for all meshs.

i think i will have a speed issue but that all what i think about.

thanks.

the wrong red plane and the black one, they are in the same model and both of them must have red color, but as i mentioned the black one his normals are flipped. enter image description here

Saif_Qaher94
  • 72
  • 11
  • Open your model in blender or similar. These program already have some algorithms to figure out the right side of each normal, at least if your model is closed. – sbabbi Mar 17 '16 at 00:33
  • is the source code available ? i want to implement this solution on my cad program. – Saif_Qaher94 Mar 17 '16 at 04:41

2 Answers2

1

OSG has a visitor class in osgUtil that can calculate all the vertex normals for you, called smoothingVisitor. You just need to point it at your model after you've loaded it, eg:

// recalculate normals with the smoothing visitor
osgUtil::SmoothingVisitor sv;
loadedModel->accept(sv);

This will clobber existing vertex normals, or create new ones if they don't exist. Just looking quickly at it, it looks like it assumes your geometry is triangles, not quads as you've drawn, but I could be wrong.

Ruan Caiman
  • 881
  • 5
  • 5
0

I suspect something is up with the indexing, if not then it is probably better to ignore the normal's table entirely. I'm not really sure about the details, but I assume it is 1 normal/vertex, so approaching it would involve calculating poligon normals, which you can do with:

normalize(cross_product(vert0 - vert1, vert0 - vert2));

After that averaging the normals of the poligons sharing the vertex should do. Calculating the dot product of the freshly calculated normal and the original normal would reveal if the original normal is way off.

Anyways for your problem StackOverflow isn't really the one, there are other Stack Exchange sites that are actually specialized for similar problems. Also there are way too few informations about the issue so helping isn't easy as well.

Geries
  • 365
  • 2
  • 8
  • hi, thanks for the reply and for suggestion me Stack Exchange, i will try to post there. – Saif_Qaher94 Mar 17 '16 at 04:37
  • and about normal yes they are vertices normals , i update the question with an image please check it. and let me know what type of information is missing. – Saif_Qaher94 Mar 17 '16 at 04:39
  • Well calculating the normal vector and then calculating the dot product of the calculated one and the default one should reliably detect issues where dot < 0.0f. http://www.lighthouse3d.com/opengl/terrain/index.php?normals There I can see actual math for your basic normal vector calculating needs. – Geries Mar 17 '16 at 12:44