Jump to content

  • Log In with Google      Sign In   
  • Create Account


Using Assimp to generate Normals for a mesh


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 KaiserJohan   Members   -  Reputation: 1096

Like
0Likes
Like

Posted 18 March 2013 - 03:00 AM

I am using assimp as a tool to import different 3d models and convert them to my own format which is then loaded by the game. I am at the point where I want to implement lightning, and one of the things I need is the normals for a mesh. 

 

I have a basic cube made in blender, which when exported does not come with any normals defined. 

 

I read about the assimp flag 'aiProcess_GenNormals' (http://assimp.sourceforge.net/lib_html/postprocess_8h.html#a64795260b95f5a4b3f3dc1be4f52e410) which sounded great, but I noticed that when I use it for some reason the number of vertices 'mNumVertices' in the mesh grows from 8 to 24, and later when I try to render it something broke in OpenGL as nothing is rendered.

 

Why would assimp possibly report triple the number of vertices in the scene when generating normals?

 

 



Sponsor:

#2 TheChubu   Crossbones+   -  Reputation: 3972

Like
0Likes
Like

Posted 18 March 2013 - 03:27 AM

Sharp edges, like the ones from a cube, don't get nicely with a single averaged normal per vertex. So Assimp is probably duplicating vertices (4 verts per face, 6 faces per cube, 24 verts in total) of each face and computing normals accordingly (ie, all 4 verts of a cube face have orthogonal normals to that face instead of averaging them all).

 

You can probably find more info in Google about how to deal with sharp meshes normals and smooth meshes normals. The method of averaging surrounding triangle normals to get a single vertex normal out of them works on the assumption that the real surface is smooth, and that you're working with a more "blocky" approximation of it. When your geometry actually represents the real surface you're trying to emulate, in this case a cube, that assumption no longer holds on and it screws up lighting calculations.


Edited by TheChubu, 18 March 2013 - 03:36 AM.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#3 KaiserJohan   Members   -  Reputation: 1096

Like
0Likes
Like

Posted 18 March 2013 - 03:59 AM

So since each vertex is part of 3 faces, there will exist 3 duplicates, and each of those have a unique normal even though they share the same vector data?

 

A little of topic but.. is there any way to 'debug' the workings of a shader? It compiles fine and all but after I tried to implement lightning nothing simply gets rendered and I can't find another way to fix it rather than manually double check all OpenGL related code over and over



#4 Olof Hedman   Crossbones+   -  Reputation: 2715

Like
0Likes
Like

Posted 18 March 2013 - 04:10 AM

Yes, Assimp is most definitely duplicates the vertexes, since you can have only one normal per vertex, and there is no other way to represent the sharp edges of the cube without duplicating the vertexes.

 

Debugging shaders is tricky, there is not really any good way. You have to be careful, and sometimes it can helpful to output debug colors.

You should make sure to read the shader log though (glGetShaderInfoLog), you often get hints there of potential problems and what might fail.

 

But we programmers are so spoiled :)

I've started doing some electrical engineering in my spare time, I've spend 4 days now designing and etching a circuit board, and I still don't know if it will work!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS