|
 |
"Kenneth" <kdw### [at] gmail com> wrote:
> However, this is NOT a fault of your conversion process: I noticed the same
> behavior while working on my own POV-ray STL-to-mesh converter. The 3 vertices
> in each STL triangle are apparently written the opposite way 'around the clock'
> -- opposite chirality-- according to how *POV-ray* expects them. I had to fix
> this in my own code, simply by swapping the triangles' 3rd point for the 1st.
> Like:
>
> an original STL triangle:
> triangle{<1,2,3>, <4,5,6>, <7,8,9>}
>
> for correct POV-ray rendering:
> triangle{<7,8,9>, <4,5,6>, <1,2,3>}
>
> STL files (and 3D printers) are apparently standardized for a 3-vertex chirality
> that is opposite to POV-ray's own triangle-rendering scheme.
Yes, our left-handed coordinate system can drive people crazy at times.
It's also why things are best coded to be adjustable.
If you put your triangle vertices into an array and referenced them by index,
then it's something that can be adjusted - and even used as data apart from the
mesh2 definition. Hard-coding the structure makes it inaccessible from SDL,
which has been a long-standing complaint in POV-Ray development.
Loading the data into an array makes it available to the user to post-process
after loading.
<-1, 0, 1> * 1 + 1 = array indices <0, 1, 2>
<-1, 0, 1> * -1 + 1 = array indices <2, 1, 0>
So everything is easily flipped with a simple pre-multiplier
It also allows mesh deformation (similar to what Josh English wanted to do)
because you have direct access to modify the data.
It also allows you to compute the normals differently.
Not saying that Sergei has to do it that way, but it definitely is something to
think about, and perhaps experiment with implementing in your own converter.
- BW
Post a reply to this message
|
|
