• 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
theagentd

What to do with old per-vertex normals when doing normal mapping?

12 posts in this topic

Hello. I have a really small question regarding how to implement normal mapping. All the model files I have already have per-vertex normals stored in them. All the tutorials/articles I've found computes all three of the normals, tangents and bitangents per vertex by averaging the triangles the vertex is part of and then orthogonalizing them. However, I can't find any information on what I should do with the already existing per-vertex normals. What are 3D programs that generate normal maps etc expecting me to do? Should I ignore the per vertex normals, can I assume that they're already what I need (calculated the same way the tutorials/articles tell me to) or do I need to take them into consideration in some special way?

0

Share this post


Link to post
Share on other sites

Normal mapping adds 2 more normal types: Tangent and Binormal.
The normal map tells you how much to shift the normal in these directions.

Which means you use the existing normal exactly the same way as you did but adjust it in the direction of the binormal and tangent based off the values read from the normal map.


L. Spiro

Edited by L. Spiro
0

Share this post


Link to post
Share on other sites

Thanks for the response. However, what I'm asking about is a bit simpler than that. I'm asking about generating the normals, tangents and bitangents. There are already normals in my 3D models, but the articles are telling me to calculate a normals, tangents and bitangents by averaging triangles. If I use the normals in the 3D models I may not get orthogonal vectors, but if I calculate a new one I'm ignoring the one that came with the model.

0

Share this post


Link to post
Share on other sites

It simply depends on whether you find the pre-computed normals usable or not. If they differ much from your own calculations or give poor lighting results you might feel like throwing them out. Tangent vectors can always be orthonormalized in respect to a normal vector.

1

Share this post


Link to post
Share on other sites

Normal mapping added 2 more normal types: Tangent and Binormal.

biTANGENT. Binormal is nonsensical in this context.
0

Share this post


Link to post
Share on other sites

biTANGENT. Binormal is nonsensical in this context.

 

Why is that? The semantics in HLSL at least, are TANGENT and BINORMAL.

0

Share this post


Link to post
Share on other sites
If you're using 'baked' normal maps, (which are authored by copying the details from a high poly model onto texutres for a low poly object) then your engine and modeling tools both need to use the exact same t/b/n vectors. So in some cases you need to be able import these as well as the normals from your art tools.

In other cases, you can import just the normals, and then generate the t/b, or you can generate all three.



biTANGENT. Binormal is nonsensical in this context.

Why is that? The semantics in HLSL at least, are TANGENT and BINORMAL.
Depending on which branch of mathematics you're using, one of either one of them is the properly defined term (and the other is nonsense).
In computer graphics though, we use them interchangeably.
1

Share this post


Link to post
Share on other sites


Normal mapping added 2 more normal types: Tangent and Binormal.

biTANGENT. Binormal is nonsensical in this context.


Read reply by Hodgman. I typed “Bitangent”, erased it, and specifically typed “Binormal” in order not to confuse the original poster who is likely used to seeing HLSL semantics or tutorials commonly referring to it as such.


L. Spiro
1

Share this post


Link to post
Share on other sites

ead reply by Hodgman. I typed “Bitangent”, erased it, and specifically typed “Binormal” in order not to confuse the original poster who is likely used to seeing HLSL semantics or tutorials commonly referring to it as such.


L. Spiro

That's fine, I'm aware of the confusion around it so everyone should just use whatever they're used to. I'm using GLSL by the way, but that's not really relevant. smile.png

 

 

If you're using 'baked' normal maps, (which are authored by copying the details from a high poly model onto texutres for a low poly object) then your engine and modeling tools both need to use the exact same t/b/n vectors. So in some cases you need to be able import these as well as the normals from your art tools.

In other cases, you can import just the normals, and then generate the t/b, or you can generate all three.

 

I see. That's what I was a bit worried about, but I'm using .smd files which only contain normals. I'm already "compiling" my .smd files to an internal format in my engine in which I store the (generated) tangents, and using the normal and tangent I can generate the bitangent/binormal using a cross product between them. Assuming I can get my hands on tangents and/or bitangents I can store them in my compiled format.

 

I'm not done implementing normal mapping yet, but I've taken the approach where

1. generate a tangent

2. orthogonalizes it to the normal

3. generate the bitangent using a cross product between the normal and the tangent

 

Since I'm at least respecting the normal information in the model, shouldn't this have a close to or maybe even identical result to what the modelling program was using?

0

Share this post


Link to post
Share on other sites

Since I'm at least respecting the normal information in the model, shouldn't this have a close to or maybe even identical result to what the modelling program was using?

No, there are many methods to generate the t/b vectors, given a normal. Any t/b/n basis per vertex is valid, provided they're all perpendicular. This means if you rotate the basis around the normal axis, you've still got valid data. You can even flip one axis in the reverse direction (e.g. Do Binormal = -Binormal), and you've still got a valid t/b/n basis.

Also, art tools generally try to take the UV/texture coordinates into account when generating the t/b vectors, so that the Tangent points in the same direction the U (x texture coord) is increasing, and the Binormal/Bitangent point in the direction the V (y) is increasing. This makes the normal map texture make a but more sense to look at and edit by hand ;) This also means that if the UVs are flipped at one point (e.g. The artist only textured half a face, but then used he same UV layout on both sides of the face, causing a mirroring in the tex-coords down he centre) then your binormals might also flip direction arbitrarily. If you're using artist-generated data, you often can't throw out the Binormal and just recreate it with a cross product -- you need to at least store a single bit encoding whether the cross product should be multiplied with 1 or -1.

This means that unless you know the algorithm being used by your art tools, it's very likely that your engine will produce different results...
Putting a normal map onto a brick wall is fairly simple, but handling all the little problems that come up when modeling a character is a lot more complex ;(

That model format is from the Source engine, right? Maybe there's source code for a loader/importer/compiler/viewer in the Source SDK, and you can copy their TBN generation algorithm?
0

Share this post


Link to post
Share on other sites

I currently only calculate the tangent using vertex positions and UV coordinates. I see now that I've made a few assumptions that may not always hold.


I decided on smd-files because it was the only format that supports skinning AND actually makes sense to me, so I'd prefer it if I could keep on using them. I'm pretty sure that the normal maps will be generated from a high-poly model, which I assume is done by a separate program. Skinning and animating is done in yet another program and is completely unrelated to the normal maps, so in theory it should be possible to in some way export the normals, tangents and bitangents into a separate file from the low-poly generating program (together with the normal map) and use them together with the .smd file to compile it all into my own format. Although it's far from optimal, it's the easiest solution I can think of right now.

 

Although the format is used by the Source engine, the models are custom made from scratch. After some quick googling I found this thread: http://www.polycount.com/forum/showthread.php?t=107420. It seems to suggest that the Source engine follows certain standards, but I'm a bit unsure what programs our modelers use (it's a hobby project so we're not terribly organized ^^'). I will try to speak with them as soon as possible to figure out the details.

 

Thanks a lot for your input, everyone! I had no idea that this would be so difficult to implement.

0

Share this post


Link to post
Share on other sites

I thought I'd just add a small post to wrap up this thread.

 

I spoke to one of our modelers and got my hands on a few test models. After a few tests and a some bug squashing we finally got some code that actually looked decent. The solution isn't perfect; some surfaces look rounded when they should be flat, but the problems are very minor so unless I encounter a model that has any visible quirks I'll probably stick with my current code. It's a bit disappointing though. I implemented my shaders exactly like I the example for MikkTspace (don't normalize tangent/bitangent/normal in the pixel shader, but normalize the calculated normal), but the result is still not perfect, so it has to be how I calculate the tangents...

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