Hi Nicola,
There was a lengthy discussion of smoothing a while ago on the forums:
http://forums.ldraw.org/showthread.php?tid=8595,8688
...I ended up implementing smoothing in BrickSmith based on the discussion. So a few things:
1. Does your original code handle smoothing of rounded surfaces made of triangles too or only quads? The algorithm that I ended up using uses triangles, and thus decomposing the quads is not a problem.
2. The Bricksmith mesh smoother is a straight cross-platform pure C API, and it translates lines, tris and quads into indexed GL meshes - I think you could probably just use it under BrickSmith's open source license.
http://sourceforge.net/p/bricksmith/code...shSmooth.h
http://sourceforge.net/p/bricksmith/code...shSmooth.c
3. For modifying your code to handle this case, I think there are two things you _must_ do:
- You must be prepared to smooth a vertex by an _arbitrary_ number of incident triangles - in other words, think of all triangles touching vertex V as a fan - every one of them may contribute to smoothing, and there can easily be more than 4 - there will be 6 in the case of quads (because of the necessary split) or more for other LDraw shapes.
- When you find all incident triangles, you must weight the averaging of the normals by the _angle_ of the triangle at vertex V. If you do not do this, the direction of the normal will be biased and you will get a smooth mesh, but a smooth mesh whose lighting appears to run at an angle along the split line of the quads.
Finally, just a quick note: the BrickSmith code matches LDView in that it smoothes any edge that is not sharp and does not have a line - it does not require conditional lines to induce smoothing. My thinking on this was: you can easily create a renderer that looks good without rendering conditional lines at all if you are doing 3-d shaded solid drawing. So I wanted to build a smoothing algorithm that would not require conditional lines since they were already unnecessary for the rest of BrickSmith.
I've been meaning to write up a document based on the discussion - people covered fixing the loss of precision due to rotation matrices, detecting and repairing T junctions, etc.
Cheers
Ben
There was a lengthy discussion of smoothing a while ago on the forums:
http://forums.ldraw.org/showthread.php?tid=8595,8688
...I ended up implementing smoothing in BrickSmith based on the discussion. So a few things:
1. Does your original code handle smoothing of rounded surfaces made of triangles too or only quads? The algorithm that I ended up using uses triangles, and thus decomposing the quads is not a problem.
2. The Bricksmith mesh smoother is a straight cross-platform pure C API, and it translates lines, tris and quads into indexed GL meshes - I think you could probably just use it under BrickSmith's open source license.
http://sourceforge.net/p/bricksmith/code...shSmooth.h
http://sourceforge.net/p/bricksmith/code...shSmooth.c
3. For modifying your code to handle this case, I think there are two things you _must_ do:
- You must be prepared to smooth a vertex by an _arbitrary_ number of incident triangles - in other words, think of all triangles touching vertex V as a fan - every one of them may contribute to smoothing, and there can easily be more than 4 - there will be 6 in the case of quads (because of the necessary split) or more for other LDraw shapes.
- When you find all incident triangles, you must weight the averaging of the normals by the _angle_ of the triangle at vertex V. If you do not do this, the direction of the normal will be biased and you will get a smooth mesh, but a smooth mesh whose lighting appears to run at an angle along the split line of the quads.
Finally, just a quick note: the BrickSmith code matches LDView in that it smoothes any edge that is not sharp and does not have a line - it does not require conditional lines to induce smoothing. My thinking on this was: you can easily create a renderer that looks good without rendering conditional lines at all if you are doing 3-d shaded solid drawing. So I wanted to build a smoothing algorithm that would not require conditional lines since they were already unnecessary for the rest of BrickSmith.
I've been meaning to write up a document based on the discussion - people covered fixing the loss of precision due to rotation matrices, detecting and repairing T junctions, etc.
Cheers
Ben