It appears not to be configured to use ldconfig.ldr. It also appears not to be using subdued lighting (which may be intentional). I'll talk to Chris about fixing the configuration.
(When ldconfig.ldr support was first added to LDView, it didn't work well with metallic and chrome colors, so I made the default off. At this point in time, that's probably not a good default. I'll probably change it in the next release.)
The antialiasing looks really good on the edge lines. Is there a way to get ldview to antialias the edges of the printed polys as well? Alternatively, is FSAA available with the osmesa renderer? Or as a last resort, render at 2x and resample back down with a post processor like imagemagick to smooth out the edges of the printed bits.
No, antialiasing the edges of printed polygons isn't supported. It on the list of potential future enhancements. FSAA also isn't supported by my OSMesa renderer. I strongly suspect that OSMesa itself does support it, since it seems to be pretty full-featured. I'm not sure how hard it would be to integrate support for it into my OSMesa LDView. I could probably also implement fake FSAA in LDView in the snapshot saving code. Multiplying the line widths by two and then doing a 2-to-1 downsample by averaging each group of 4 pixels would be pretty straightforward.
I suspect "fake FSAA" snapshots would really improve the legibility of the printed parts on the tracker. So it'd be really cool if you could pull that off.
I believe the postprocessing FSAA technique was used on
these instructions and you can see the printed parts look much better than they would without it.
The configuration problem has been fixed and all images re-generated.
Chris