Jump to content
  • Advertisement
Sign in to follow this  
Stoic

Vertex Normals with Creases

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!