Roland Melkert Wrote:What are you two doing to me, I've just rewrote the vertex processing code for LDCad this weekend
Yep - I suspect that I will have written smoothing for Bricksmith completely twice over by the time this is all done. But ... such research is probably necessary to fully understand the problem; you and anyone else on the leading edge are essentially doing that research.
Quote:I like the opt-out approach Ben is suggesting, but I also would like to do some more coding/testing to see how far the real-time (brute force) approach can be pushed, before adding any new meta's.
Agreed -- a perf optimization META is pretty useless if there isn't a perf problem. I think at the rate we are rapid-prototyping and the rate that spec change are approved, we'll have good test apps in plenty of time. :-)
Quote:One thing we might be overlooking is the fact parts also need to be BFC certified for reliable smoothing. This seems to be the biggest problem in my current setup.
I can confirm what Travis says: neither BFC certification in the model change nor BFC awareness in the renderer are necessary to smooth. This was a good thing for me...BrickSmith's rendering path ignores BFC completely. :-) (And generally it's nice that smoothing isn't dependent on BFC cert being 100%.)
I prefer to think of the problem in terms of 1-sided and 2-sided geometry. A BFC-aware program processing BFC cert geo is essentially creating a series of one-sided triangles - the program can use the BFC invert stack to reverse triangle winding so that the end data set is entirely CCW. A BFC-unaware program draws everything two-sided and must cope with back-facing normals.* I mention this because a 2-sided lighting program must somehow be able to cope with wrong-facing normals already, so having some normals face backward without smoothing is not a problem -- in fact, every normal faces the wrong way half the time as you rotate the model.
Two triangles face in opposite directions if they have a common edge whose vertices go in the same order in both triangles. So...um...
Code:
C
/|\
/ | \
/ 1|2 \
A---B---DIf you have triangle ABC and triangle SPAM CONTENT then the common edge BC is in opposite order between the two tris (BC in the first and CB in the second). Thus you know they are wound in the same direction for a given plane, and the crease is measured via the dot product of the CCW normal of each. (In other words, this is the 'sane' case.)
But if you have triangles ABC and triangle BCD, nwo the edge BC is in the same order in both triangles...one is CCW and one is CW (for a given viewpoint). In this case you need to do one of two things:
- One-sided case: treat them as not connected - they're not visually connected or
- Two-sided case: treat them as flipped.
So in BrickSmith's case, when I find this common edge I mark 1 and 2 as "flipped neighbors", not "regular neighbors." When I calculate the normal of B1 (that is, vertex B, for triangle 1), I flip the normal of 2 to get a normal facing in the direction that 1's face normal was facing, but smoothed. Then when I go back and calculate B2 (that is, vertex B for triangle 2), I flip the normal of 1 to get a normal facing in the direciton that 2's normal was facing, but smoothed.
Since the smoothing function is the same for B1 and B2, I get the same normal, but in opposite directions, and the lighting looks continuous since the lighting is two-sided.
My indexing-consolidation pass runs _after_ all normals are calculated (so that I only 'merge' 100% smoothed vertices). In this case, B1 and B2 both go in my VBO separately because their normals are different.
This case happens most often in things like mirrored sw minifig heads - every 'seam' at the mirror line is a flipped neighbor case. If I were to track BFC cert and keep an eye on the matrix inverts, I could have simply taken the mirror-half of the minifig head and flipped the order of all vertices.
* Allen originally solved this with a clever trick: the lighting environment is mirrored around the XY plane, so back-facing triangles are lit from behind and appear correct. With the new shader-based renderer, I simply flip the noraml in-shader if it is facing the wrong way in screen space.