Andy Ross <[EMAIL PROTECTED]> said: > 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 precisely *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.
Not true to the first part. Check out this screenshot of flaps isolated from the 747 model: http://www.spiderbark.com/fgfs/flapshade.png These are identical, except that the edges don't share vertices on the flap on the right. Yes it is likely that the crease value is exactly for this purpose, but we are not talking about supporting that property. Changes to the ssg structure would be required...while we are at it, there should also be a place for the shading flag. > 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. We aren't all that far off from what I can see. > Your preference seems to be that it guess "dumbly", leaving as much > flexibility as possible in the hands of the modeler. 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 people who understand the models? I'm not against leaving this in, but it should be optional, and that we can initiate with a setting in the model's xml wrapper. > Most > of the time, it does the right thing; and hand-splitting vertices is a > real pain for the modeler if they are forced to do it on every sharp > edge. Try hand-splitting the Cub's engine, for example. It is very easy in ac3d: Object/Fragement followed by Object/Merge. Or if only a group of surfaces need to be done like the top of a flap, select the surfaces and then Surface/Cutaway Object followed by selecting the two resulting objects and then Object/Merge. Lee and others do it all the time, except currently we cannot combine the surfaces back together in one object because plib will merge those vertices that were created. AC3D does not do this merge, even on reloading the model data from the ac file. > And regardless, you can (or should be able to, modulo bugs) force the > splitter off by setting the threshold to zero. A little more definitive setting would be better, but yeah that would work. The same goes for having a function to set the "distance slop" (optmise_vtol[0]) as was discussed earlier. If the tolerance test was "> tolerance" then identical vertices would not be merged if the setting was 0. But a flag would be better documentation for this too. > 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. There is a bit of code in the existing OptVertexList::makeNormals() that attempts to deal with those. After a patch in cvs it still doesn't work. You'll see it in there (it makes a straight up normals when it finds one). The problem is that while the current method of detecting these is slightly better, it still gets false positives on certain arrangements of triangles on planes whose axes are parallel to the XZ. I haven't yet thought out why it is that the current shortcut (normal length test) fails. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
