On Thursday 02 October 2003 21:21, Jim Wilson wrote: > Lee Elliott <[EMAIL PROTECTED]> said: > > > On Thursday 02 October 2003 03:52, Jim Wilson wrote: > > > BTW there is a plib bug showing up on the bottom. That is one example > > of how > > > the ac3d loader really is screwing up the shading. My guess is the > > > optimization is to blame. Checking it out in wire frame mode (in > > flightgear) > > > might reveal something. It would be awful nice to do away with that > > step. > > > > Oops - I thought I'd got 'em all;) I'll have a look at it. The model > > loader/renderer does do some funny things at times - I've been re-working > > the TSR-2 and hit a problem on the front canopy inner lining where a > > couple of sections seemed to be clipped out of it in fgfs. I remember > > you showing me some screen shots of a similar problem you had with the > > tip of the p-51d control-stick. Anyway, I could see that the missing > > sections were the diagonal halves of the original rectangle so I thought > > I'd manually triagulate the effected polys but switch the orientation of > > the diagonal. > > > > It made no difference at all, which was strange - the new triangles > > couldn't be re-triangulated to produce the missing sections and it wasn't > > a case of particular triangles being missed because the new triangles ran > > across the missing area:/ > > > Then I went back to the original rectangular polys and tried sub-dividing > > them. This actually changed the shape of the missing sections but didn't > > fix it:\ > > > > Fortunately, re-sizing it a little did:) > > That works sometimes. The problem is that the optimization tries to merge > polys together that it thinks it can. The exact criteria I haven't gotten > into yet. Probably looking harder at the code would reveil the exact process. > The reason I haven't looked hard is that I am fundamentally opposed to having > plib DO ANYTHING to change my model when it loads it. > > It seems that the plib ac3d loader will eat vertices (so to speak) when all > the vertices are within a certain tolerance of each other as opposed to exact > matches. Probably Steve or whoever wrote the optimization was trying to > compensate for sloppy modeling and by merging together vertices that were > really close togehter. Of course this begs the question of what do you call > really close? That is where the problem lies. > > Another thing that I found works can only be used when the surfaces are > untextured or textured with a solid color or pattern. If you map adjacent > surfaces differently, then the vertices won't line up in the file. For > example, map one surface to XY and the next to XZ the next to XY and so on. I > used that method to fix some knobs in the 747. The reason why it works > probably has something to do with the optimizer _not_ reordering vertices to > find a match. That would result in a different normal with AC3D models. > > Last I looked at the code it seemed as though we could customize a good part > of the ac3d loader in simgear without having to redo or copy the entire guts > of it. It would be _really_ nice to have this fixed. > > I'm not sure that the people who have opposed reimplementing the loader or > making a greater effort to persuade Steve Baker to accept a fix realize how > much time is involved frigging with these stupid little glitches that the > optimizer introduces. > > Best, > > Jim
Ta for the explanation - it makes some sort of sense now and is understandable in the context of 'loose' vertices. I'd much rather it didn't try any optimisations with the geometry though - it's better fixed by fixing it in the model, imo. As this problem is mostly encountered with small objects, where the vertices are close together, I've wondered about it occurring while modelling VC instruments. I've not tried doing any yet but considering how easily it can occur with something the size of a canopy hoop, the thought of trying to sort it out on an instrument part, like a needle is a bit off-putting. Have you had many problems with the instruments you've done? LeeE _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
