• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
jor1980

How to calculate normals for a trianglemesh?

17 posts in this topic

Hi, I am creating a meshviewer using jme3 I read the meshes data from a file that has no normals data. So I need to create them with my code but I don´t know how can I create the normals for a trianglesmesh from my java code in jmonkey.

0

Share this post


Link to post
Share on other sites

For polygons, cross product two of the edges. Like (v2-v1)x(v3-v2). Then normalize it.
 

Once you have all the face normals, you can calculate vertex normals by averaging all the face normals that the vertex belongs to. Easiest way to do it is to zero out all the vertex normals, then loop over all the faces and add the face normal into each of its vertices' normal. Then loop over all the vertex normals and normalize them.

0

Share this post


Link to post
Share on other sites

For polygons, cross product two of the edges. Like (v2-v1)x(v3-v2). Then normalize it.

If the winding order for the triangle is v1, v2, v3 - the crossproduct should be (v2-v1) x (v3-v1) to get the correct direction, assuming that clockwise winding order implies left-hand rule crossproducts and counter-clockwise order implies right-hand rule crossproducts.

 

Also, if the mesh faces do not share vertices - i.e., a vertex is used in only one face - the algorithm DekuTree64 will work, but comprises a lot of extra calcs. In this case, simply calculate the face normal via the crossproduct mentioned and set the normal for each of the 3 face vertices to that face normal.

Edited by Buckeye
0

Share this post


Link to post
Share on other sites

In this case, simply calculate the face normal via the crossproduct mentioned and set the normal for each of the 3 face vertices to that face normal.

Wouldn't that produce ugly lighting results?

 

EDIT: For anything that isn't a cube that is.

Edited by TheChubu
0

Share this post


Link to post
Share on other sites

 


For polygons, cross product two of the edges. Like (v2-v1)x(v3-v2). Then normalize it.

If the winding order for the triangle is v1, v2, v3 - the crossproduct should be (v2-v1) x (v3-v1) to get the correct direction, assuming that clockwise winding order implies left-hand rule crossproducts and counter-clockwise order implies right-hand rule crossproducts.

 

Also, if the mesh faces do not share vertices - i.e., a vertex is used in only one face - the algorithm DekuTree64 will work, but comprises a lot of extra calcs. In this case, simply calculate the face normal via the crossproduct mentioned and set the normal for each of the 3 face vertices to that face normal.

 

If he's reading the mesh from a file, the only way to know if a face is not connected to other faces is going through all the faces and checking if any of it's vertices are in the face you're interested. And if you check every face you'll have to iterate over the full mesh a lot of times.

 

To me it looks like more work, with DekuTree64 method you must go over the vertices once (to set the vertex normals to 0), over the faces only once (to compute the face normal and add it to each vertex of that face), and then over the vertices once again (to normalize the vertex normal).

0

Share this post


Link to post
Share on other sites

Wouldn't that produce ugly lighting results?

EDIT: For anything that isn't a cube that is.

Cubes aren't the only thing with "flat" faces. smile.png He didn't mention whether the mesh in question was organic, a mechanical object, etc. Buildings, platforms, etc., look much better with flat faces.

 

 

 


If he's reading the mesh from a file, the only way to know if a face is not connected to other faces is going through all the faces

Not necessarily. If a mesh is loaded for a specific purpose in a scene, etc., one would know the characteristics of the mesh. If the mesh is known to have "flat" faces, I'd skip the extra calcs. That's why I qualified my comment with "if the mesh faces do not share vertices.."

Edited by Buckeye
0

Share this post


Link to post
Share on other sites

The mesh in question is a human face. As i am using jmonkey i would like to know if it has any method to make all this calculations or if is it another java api to make this calculations?

0

Share this post


Link to post
Share on other sites

I made what you told, calculate the face´s normals and then lopp throw the vertex to calculate the vertex normals. My result is very confusing, despite i set facecullmode to off, this is my render result:

 

Any clue about the problem?could be something with the normals calculation?l5jn.jpg

0

Share this post


Link to post
Share on other sites

Reviewing my code and the results I got I think that my problem is that some os the faces are clockWise and other counterclockwise, as I didn´t know how to determine if a face  is clockwise or counterclockwise I calculated the face's normals like this:

//Calculate the face normal, true for clockwise false counterclockwise(not confirmed)
		static Vector3f calculateFaceNormal(Vector3f v1,Vector3f v2,Vector3f v3, Boolean isClockWise){
			//cross product
			Vector3f crossProduct;
			if(isClockWise)
				crossProduct=v2.subtract(v1).mult(v3.subtract(v2));
			else
				crossProduct=v2.subtract(v1).mult(v3.subtract(v1));
			
			//normalize
			return crossProduct.normalize();
		}

So I think that I must change this code in a way to know if a face is clockwise or counterclockwise and then choose the right crossProduct for it. but I don´t know how to determine that.

0

Share this post


Link to post
Share on other sites

The file must be saved using some convention, every face should be stored clockwise or counterclockwise. But I'm guessing that when you open the file in another program it shows ok, right? Can you share the file? I'd like to take a look of it. Have you tried other files?

0

Share this post


Link to post
Share on other sites

The file is from a game and you need to understand it to extract the data so if i put the file you couldn´t see nothing clearly, what I can do is extract the vertex positions as binary file telling you the dataformat, and also extract the trianglestrip in another binaryfile.Is it right for you?

 

The file in its game shows the mesh correctly

0

Share this post


Link to post
Share on other sites

Hmm... That's like the exact result I had when I imported .obj files that weren't triangulated. Basically, half the indices were missing.

0

Share this post


Link to post
Share on other sites

Oh, I thought you were opening a file and reading every vertex and face directly from the file, but it sounds like the file stores the information in a different way and the you make a vertices and faces list, right?

 

I was looking at the .m3d file you uploaded, and if you look at two consecutive faces you'll see that most of the times one is clockwise and the other is counterclockwise:

 

For example:

13 14 15 <- if this is counterclockwise
14 15 17 <- this would be clockwise

 

Since those 2 faces share a side (from vertex number 14 to vertex number 15) the second line should be "15 14 17" instead. Maybe the code that reads that model and generates the list of vertices and faces is doing something wrong. Before you posted a triangle strip, does the original file specify the way to draw it? I guess maybe it stores something like "13 14 15 17" and the file loader makes a face for 13 14 15 and the other for 14 15 17 when the second face should be 15 14 17. If you use the vertex directly to draw a triangle strip, OpenGL makes that swap for you.

 

As for the question you posted before about knowing if a face is defined clockwise or counterclockwise, unless the file format stores something that specifies it there's no way to tell. In a three dimensional space, a face is defined clockwise AND counterclockwise, it's relative to where the camera is standing. What you could do (with A LOT of work) is check if a normal is pointing outside or inside of the model, but it's not easy and for sure is not trivial.

0

Share this post


Link to post
Share on other sites

I think you are right, the triangleList was created by me with my own code deleteing degenerated triangles, and not changing the order of the vertices in the triangles.

I was trying now triStrip methos of jme3 to build the triangleStrip but i think i can´t use because it optimize the triangleList making that some vertices doesn´t belong to any face and when I import the mesh to blender i get errors.

So to test it your theory is right i need to create a correct triangleList to see if the mesh is rendered ok.

 

i have to two options, find an api that create a triangleList without optimize it, or change my code to create the triangleList in a right way, but I still don´t know how to do it.

 

Here is the code I use to create the triangleList:

static List<Vector3f> createTriangleListFromStrip(ByteBuffer stripBuffer){
		
		List<Vector3f> facesList= new ArrayList<Vector3f>();
		stripBuffer.clear();
		
		int a=0;
		int b=0;
		int c=0;
		int flagPar=0;
		
		for(int i=0;i<(stripBuffer.capacity()/2)-2;i++){
			
			if(i==0){
				a=Short.reverseBytes(stripBuffer.getShort());
				b=Short.reverseBytes(stripBuffer.getShort());
				c=Short.reverseBytes(stripBuffer.getShort());
				
				if(a!=b & a!=c & b!=c ){
					Vector3f face= new Vector3f();
					face.setX(a);
					face.setY(b);
					face.setZ(c);
					facesList.add(face);
				}
			}
			else{
				a=b;
				b=c;
				c=Short.reverseBytes(stripBuffer.getShort());
				
				if(a!=b & a!=c & b!=c ){
					Vector3f face= new Vector3f();
					face.setX(a);
					face.setY(b);
					face.setZ(c);
					facesList.add(face);
				}
			}
		}
		return facesList;
	}
0

Share this post


Link to post
Share on other sites

Try something like this:

static List<Vector3f> createTriangleListFromStrip(ByteBuffer stripBuffer){
		
		List<Vector3f> facesList= new ArrayList<Vector3f>();
		stripBuffer.clear();
		//Maybe you need to check if stripBuffer has enough elements, I'm not sure if you test that before calling this method
		int a=Short.reverseBytes(stripBuffer.getShort());
		int b=0;
		int c=Short.reverseBytes(stripBuffer.getShort());
		
		for(int i=2;i<(stripBuffer.capacity()/2)-2;i++){ //check if the "-2" still makes sense, I'm not sure what capacity() returns (byte size maybe?)
			
			if(i%2==0) {
				b = c;
			} else {
				a = c;
			}
			
			c = Short.reverseBytes(stripBuffer.getShort());
			
			if(a!=b & a!=c & b!=c ){
				Vector3f face= new Vector3f();
				face.setX(a);
				face.setY(b);
				face.setZ(c);
				facesList.add(face);
			}
		}
		return facesList;
	}

Also, doesn't Vector3f have a constructor with parameters? If you can do something like

Vector3f face= new Vector3f(a,b,c);
faceList.add(face);

the code is much readable.

Edited by DiegoSLTS
0

Share this post


Link to post
Share on other sites

Your code works ok, i made my own but was wrong, Now  the mesh I think looks almost correct maybe there is one triangle with the normal inverted at the bottom or with  another error, but this the result now:

ao71.jpg

 

I would like that this mesh looks like in blender, but i don´t know if my problem is the material or the lights.

This is the blender look:

uylo.jpg

Edited by jor1980
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0