Hi Roland,
Yep - exactly what I expected with 6085: - a rounder-than-real life shading. :-)
I think you may find per pixel lighting makes the lighting effect _worse_...particularly if you use per pixel lighting for what it's really good for: shininess. (The problem with per-vertex lighting is that the fall-off from specular hilights is very steep, so the hilight tends to be contained entirely within one triangle. Once you have that 'sharp' hilight, the induced roundness will make lighting that really looks...well...round.) I hadn't noticed the error on the slope bricks because they look nice for the roundness of the lighting.
I just coded a smoothing algorithm (which, having not run it yet, I must assume works perfectly :-), but it takes the opposite approach: it uses only lines, rather than only angle, to do smoothing/creasing. I'll post some pics once I have it integrated, which may not be for a few days.
Having gone through the coding exercise, I think I can state a 'wish list' of assumptions about the library for a smoothing algorithm:
1. The bit-wise locations of all colocated vertices match exactly - that is, no floating point jitters between vertices that should touch.
2. All faces that form a smooth edge share the (bitwise) same coordinate values and the (bitwise) same transform stack. (In other words, if you want two sub-parts to mesh smoothly, they must be transformed in the same way.)
3. All parts are BFC valid. (Because of this, two adjacent faces will have edges going in opposite directions along the triangle.)
4. Any lines used to indicate a crease have a start and end point that (bitwise) matches the location of the corners of the triangle edge that they crease. (The line does not have to go in any particular direction, as it will always match one of the two triangle faces.)
This wish list allows apps that smooth meshes to avoid any epsilon math checks, computational geometry tests, etc. Smoothing behavior is (theoretically) predictable:
- every exactly manifold edge that doesn't have a manifold line is smooth.
- every exactly manifold edge that has a manifold line is creased.
- non-manifold edges are crease (or rather, aren't eligible for smoothing because they aren't even considered to be connected).
Cheers
Ben
Yep - exactly what I expected with 6085: - a rounder-than-real life shading. :-)
I think you may find per pixel lighting makes the lighting effect _worse_...particularly if you use per pixel lighting for what it's really good for: shininess. (The problem with per-vertex lighting is that the fall-off from specular hilights is very steep, so the hilight tends to be contained entirely within one triangle. Once you have that 'sharp' hilight, the induced roundness will make lighting that really looks...well...round.) I hadn't noticed the error on the slope bricks because they look nice for the roundness of the lighting.
I just coded a smoothing algorithm (which, having not run it yet, I must assume works perfectly :-), but it takes the opposite approach: it uses only lines, rather than only angle, to do smoothing/creasing. I'll post some pics once I have it integrated, which may not be for a few days.
Having gone through the coding exercise, I think I can state a 'wish list' of assumptions about the library for a smoothing algorithm:
1. The bit-wise locations of all colocated vertices match exactly - that is, no floating point jitters between vertices that should touch.
2. All faces that form a smooth edge share the (bitwise) same coordinate values and the (bitwise) same transform stack. (In other words, if you want two sub-parts to mesh smoothly, they must be transformed in the same way.)
3. All parts are BFC valid. (Because of this, two adjacent faces will have edges going in opposite directions along the triangle.)
4. Any lines used to indicate a crease have a start and end point that (bitwise) matches the location of the corners of the triangle edge that they crease. (The line does not have to go in any particular direction, as it will always match one of the two triangle faces.)
This wish list allows apps that smooth meshes to avoid any epsilon math checks, computational geometry tests, etc. Smoothing behavior is (theoretically) predictable:
- every exactly manifold edge that doesn't have a manifold line is smooth.
- every exactly manifold edge that has a manifold line is creased.
- non-manifold edges are crease (or rather, aren't eligible for smoothing because they aren't even considered to be connected).
Cheers
Ben