Jim Wilson wrote: > That might be difficult to implement in plib anyway. I did a little > looking into this recently (as a parameter setting by the app, not a > ac3d 4.0 attribute). Basically my investigation revealed that plib > would have to split vertices (create duplicates on adjacent > polygons) if their normal values were greater than x degrees from > each other. The biggest problem is it would slow down the loader so > much to make it useless for flightgear scenery objects.
I have working code that does this, from my game project a few months back. Indeed, the idea is to start at each vertex in the mesh and walk around it, checking the angle of each edge you cross. Angles sharper than your threshold are flagged. You end up with a list of "zones" of smooth edges, which each get a new vertex with an appropriately averaged normal.
The basic idea is pretty simple, but the edge cases (non-closed meshes, for instance) turned out to be enormously hard to get right. But the final result looks really good -- none of the "diagonal shading stripes" that you see on many of the aircraft wings due to being mis-lit at a corner. And it's really not slow at all -- it happens only at load time, and in my experience was noise compared to the I/O and parsing overhead. It does, obviously, increase the vertex count; but no more than a "properly" lit/normaled model would have in the first place. And it has the notable advantage of allowing the modeller to preserve the mesh structure without worrying about vertex duplication and normal direction.
The only problem is that the code as it stands is not even remotely Plib-like. The model format is based on the syntax of the "Nasal" language that I wrote as part of the project, it contains (or is polluted by, depending on your viewpoint) support for dot3 bump mapping and prototype-quality stencil self shadows*.
* Self only, with no particular integration into the rest of the scene, thus the "prototype" quality. And it's slow currently; doing too much CPU work to get the list of front-facing normals.
But if anyone wants to play with it, the relevent code is up at:
http://www.plausible.org/andy/model.tar.gz
Specifically, take a look at Model::calcNormals(), which is the code responsible for the edge-sharpness-based vertex splitting. Ignore the TexBlock stuff, which is a texture state bucketing implementation largely useless in a Plib context (it's tied to rendering assumptions in the rest of my code).
Andy
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
