Jim Wilson wrote: > I'm not sure the patch is a good idea as it stands. It has to add > overhead for scenery models and it actually makes the underlying plib > problem worse...that of plib messing with the geometry data. > > It is easy to make models that look right in AC3D, the problem is that > plib runs through this optimization step that corrupts the model data. > This patch actually corrupts it even more, introducing with it other > problems.
That's not really correct. It's easy to make models look correct in AC3D precicely *because* AC3D is intelligently calculating vertex normals for you. The .ac file format doesn't even include normal data at all, so it's provably impossible to display such a file without making some sort of guess as to what the proper normal directions should be. In fact, if I understand the original "crease" issue correctly, the new version of AC3D is doing exactly the same thing that the new code is attempting to do. It's just not as simple as saying that plib is "corrupting" data -- what it gets from AC3D is incomplete. You can't do vertex lighting without normals; AC3D files don't have 'em. Plib has to make a guess. Your preference seems to be that it guess "dumbly", leaving as much flexibility as possible in the hands of the modeller. A "dumb" guess will fail (produce flat shading) for accidentally duplicated vertices, however, which is why it tries to apply some intelligence in the vertex coalescing. But that, too, fails in the presence of sharp edges, so the new code tries to recreate them by re-splitting the vertices. On the whole, I think most people agree that with the exception of a few aircraft (which are hopefully tickling fixable bugs), things look better with than without the vertex splitter. Most of the time, it does the right thing; and hand-splitting vertices is a real pain for the modeller if they are forced to do it on every sharp edge. Try hand-splitting the Cub's engine, for example. And regardless, you can (or should be able to, modulo bugs) force the splitter off by setting the threshold to zero. There just needs to be a data path from the input file and/or Plib client code through to the Plib optimizer. AC3D 4 provides this automatically via the "crease" directive, apparently. There's no reason we couldn't add the capability via other means. Anyway, looking at the bo105 model more closely, it looks like the problem isn't so much duplicate vertices (which, as it turns out, *must* be coalesced by the plib optimizer in the process of building its triangle list) but degenerate triangles. Looking only at the "rotor" object, I found a bunch of quads with four vertices, two of which turned out to be duplicates. Degenerate triangles, of course, have zero-length normals and will thus look like "sharp" edges when dotted against their neighbors' normals. I'm still looking. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
