Andy Ross <[EMAIL PROTECTED]> said: > Erik Hofman wrote: > > Andy Ross wrote: > > > Anyway, try doing a "remove duplicate vertices" pass on the > > > weird-looking models and see if that fixes the problem. I'll take > > > a look to see if I can find and reenable the old merging code. > > > > I am pretty sure I don't have them in the Fokker 50. I do > > optimizations very regularly during design time and it also isn't > > the sharping angle because it also happens in the slightly curved > > wings. > > I found the problem. The modeller (are you using Blender or AC3D?) is > generating meaningless texture coordinates. A vertex will appear once > with a UV of, say, [1 0] and then again with [0 1], etc... Plib can > combine duplicated vertices, but it won't do so when they *appear* to > be different due to differing texture coordinates. So it passes them > on to me. The original normal calculator understands this, > apparently, but I wasn't expecting to be fed geometrically identical > vertices.
Ah yes. That is exactly right. Hmmm...I wonder why this is so? If the vertices are from identical index positions why would it be looking at texture coordinates? I'm wondering if this is really an old hack that was designed to fix someone's problem with the optimiser snapping together vertices. Until a couple weeks ago it was snapping anything a centemeter or less apart. But of course it wouldn't if the uv coords were different. > My original splitter code was written to be used with with my own > blender exporter which required/enforced projected textures (the bump > mapping doesn't work well with hand-tweaked UV coordinates), so I > never noticed this issue. Or maybe Blender doesn't exhibit this > behavior; dunno. If you map adjacent surfaces to different (non-adjacent) parts of the texture then this will happen. I'm not sure about the helicopter, but the 747 has each side of the fuselage mapped to different parts of the same texture file (to get differing left and right sides). > Really, this is a problem with the modeller and/or export code; the Speaking as a modeler... I'll blame it on the plib code :-D Actually I don't quite understand as I mentioned above, why this is being done this way. > texture coordinates I'm seeing are nonsensical (the bo105 doesn't even > *have* any textures defined, yet something has generated multiple UV > coordinates for each vertex -- bizarre). Maybe...but not strange in the case of the 747 fuselage example, in the context of the ac format. > But nonetheless, painting > weird textures on a model shouldn't cause the normals (which are a > geometric property -- they have nothing to do with texturing) to look > funny. Basically, I need to preprocess the data to distinguish > "geometric" identity from "logical" identity. It shouldn't be too > hard, gimme a day or so. That would be great. It'd be nice to understand the original reason (if it was a good one). > Regardless, take a very close look at your texture coordinates and > make that unless you have a really good reason, you have only one, > unique UV tuple per physical vertex. Please may I? ;-) Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
