# Vertex Normals with Creases

This topic is 4230 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi All - I'm looking to write a vertex normal generator for my engine. Basically, given an index buffer and a vertex list, generate a buffer of corresponding vertex normals. (I'm also looking to extend it in the future to calculate Tangents, Bitangets, etc). I understand the basic algorithm, but I'm getting confused about how to determine when to "split" a vertex, based on angle thresholding, and how to determine which faces belong to which vertex in the split case. I know that in general, without splitting, you simple calculate all the face normals, then for each vertex, average the normals of all the faces it belongs to (perhaps biasing for area of the face, etc), then normalize the result and assign it to the vertex. What is confusing me is when you get into degenerate cases, Cubes being the classic case, and perhaps a Cone being one of the hardest cases. I know that you use the dot product to calculate the angle between Two normals, but what do you do when you have like 5 faces meeting along a ridge? You probably don't want to split the vertex 5 times, if say two of the faces are similar in orientation, and the other 3 are similar (but on the other side of a ridge from the other 2). The various articles and such that I've managed to dig up through Googling have all seemed to use different approaches, some ignoring some faces and not splitting at all, others going through other elaborate schemes. I can't help but feel like this is going to get complicated, where you have to do operations on each normal to determine if it qualifies to be placed in a smoothing "set" and then you split the vertex for each smoothing set. But that sounds more complicated than it has to be.... I'm mostly just looking for a kick in the brain here. What do you guys think? P.S. - I'm writing this for offline tool use. The idea is to use it in a series of mesh converters for my own engine file format. It doesn't need to be fast enough to run in real time. Thanks for any help!

##### Share on other sites
In my experience I just split the vertices according to a threshold that was variable on a per-mesh basis. Yes it generates more geometry but there were only a few isolated cases where I found this to be a genuine performance/storage problem.

It could differ in your case, but high-density meshes tend to have quite a lot of coherancy between neighbouring faces so you don't necessarily end up splitting a large number of vertices.

Ultimately it probably comes down to a trade-off of how much work you want to put in versus what sort of quality you're going to get (or lose) accordingly. Solving all cases elegantly is probably a huge task, but for a fraction of the work you could probably solve 90% of cases [smile]

Have you looked through published research papers? This sort of algorithm sounds like something that academics would be all over!

Jack

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 26
• 9
• 11
• 9
• 9
• ### Forum Statistics

• Total Topics
633711
• Total Posts
3013487
×