Hi Steve, I am breaking convention and replying on top so that your entire response below can be read by the fgfs-devel list.
This does look interesting, especially the concept of incorporating triangle area into the calculation. But there is another problem. The test case illustrated in my original post does not contain any degenrate triangles (the ac file is linked). So this could indicate an error in the averaging, or perhaps the stripifier is introducing something? The degenerate triangle issue has been known by users for quite some time, and most fgfs models do not contain any. This other problem has come up from time to time and is particularly frustrating since fixing it usually means doing something that deviates from the proper shape of the model. It does appear to be a software bug. Best, Jim http://www.spiderbark.com/fgfs/ac3dnormal1.png http://www.spiderbark.com/fgfs/ppenormal.png http://www.spiderbark.com/fgfs/ac3dnormal2.png http://www.spiderbark.com/fgfs/ac3dnormal3.png http://www.spiderbark.com/fgfs/normal.ac Steve Baker wrote: >>> Jim Wilson wrote: > Cross posted to plib-devel. > > Here is another test case that illustrates something producing considerable > difficulty for FlightGear modelers. This one results in arbitrary normals > pointing straight up. One situation that causes this are three inline > vertices on the same side of a triangle (which I can almost understand), but > this is often not the case, as illustrated in the test case. Well, we need to do *something* to avoid a divide-by-zero for the alarmingly common case of degenerate triangles in models. A triangle with all three verticies lying on the same straight line has zero area and indeterminate normal. So any surface normal is as valid as any other - and choosing (0,0,1) is a way to allow the model to load and display as best we can. The problem is (I believe) that the calculation of normals for smooth-shading averages together the normals of all the triangles sharing a particular vertex. When one of the triangles is degenerate - you get the problem you are seeing because the arbitary choice of (0,0,1) is bending the normals of the surrounding polygons in undesirable ways. There are four issues at stake here: 1) Don't make degenerate triangles! 2) We should probably weight the contribution of each normal to the overall vertex average according to the area of the triangle it came from. That improves the look of smooth shading in several ways - and results in the bogus normal of a zero (or near zero) area triangle having zero (or near zero) contribution. 3) However, even with (2), you'd still see a discontinuity at the point in your mesh where the zero area triangle is because the large triangles either side of it aren't sharing vertices...the solution to *that* can only be (1). 4) SSG treats very-nearly-zero area triangle as if they were actually degenerate. That's needed because the subsequent calculations involve squaring things - and squaring a very small number results in a VERY, VERY small number - which can easily round off to zero. So this is a case where an 'epsilon' kludge is definitely needed. Once again, there is an issue of how big that epsilon should be...but I think in this case, the epsilon is a scalar quantity - it's not in meters or parsecs or nanometers. Hence this is NOT a similar issue to the one we talked about before - and I think the present epsilon is probably OK. I'd like to see a change to the loaders to implement area-weighted normals, but that's not going to fix FGFS's problems. It'll just change a weird bright patch into a sudden brightness change. Reducing SSG's epsilon until that polygon's normal *is* calculated would 'concentrate' all of the shading change between the two larger triangles on either side into that small area - and you'd still see a 'seam' in the triangle mesh. The ultimate fix is for FGFS's tools (or the humans who use them) *not* to produce degenerate (or very skinny) triangles in the first place. Much of the effort in writing the modelling tools that we use at work is geared towards the avoidance of these ikky problems! _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
