Not long ago I was doing my semi-annual browsing at ldraw.org, just poking around to see what's new there. Coincidentally on that very same day, someone happened to submit a small enhancement request for lsynth, an ldraw program that I took on maintenance duties for many years ago when the original author ran out of steam. It was a simple request for an addition to the config file, no coding required, so I thought why not?
Naturally things got more difficult and I ended up moving both ldraw projects that I pretend to maintain from the sourceforge over to github. The sourceforge has been troublesome lately, and I'm now more familiar with github anyways. And besides, there always the hope on github that someone else will fork it, pick up the slack, and add new features.
It didn't quite work out that way. Shortly after I moved the two programs, I started getting bug reports and feature requests. Who knew there was still any demand for the old stuff? And why do I still have to do all the coding? Oh well, at least these were high quality, interesting topics. Like how to get a synthesized rubberband part to fit properly on the pins of these wheel holders, when the pin is not aligned with a convenient axis and the parts are rotated in different directions. I eventually remembered enough math to get it fixed.
I should probably put together a new lsynth release with that fix, but no sooner had I completed it when the ldglite requests started rolling in.
The idea behind one of the ldglite enhancement requests was to change the transparency rendering for some "faded" parts so the rear faces and edge lines don't show. It wasn't to difficult to whip up some test code that does it with an extra run through the render, updating only the depth buffer, before a final render pass to draw the edge lines. It should be reasonably fast if I only do it for certain transparent parts. At least that's the plan, I think...
Here's a picture. More later.
Another aspect of that feature request was to support more than one level of transparency in ldglite. Ok, ldglite uses an ancient deprecated polygon stipple technique for transparency. And back in old school days, when there were 16 or at most 256 colors available, we had some commonly used 25% and 75% stipple patterns to mix up some more colors. So I added those to the 50% pattern already in ldglite to get to three levels of transparency for fade effects. That should be enough. Hopefully downsampling the new patterns won't produce any painfully hideous aliasing effects.
Here's a shot with the 75%.
And here's the 25%.
Another of the requests was to come up with a simple way to provide a glowing silhouette in some selected color for certain parts. I've started work on that, but so far I only have this really unimpressive picture. For some reason the opengl driver is ignoring line widths (and antialiasing) so the glow is reduced to that feeble yellow outline that you can barely make out on the black technic pin.
Heh, it turned out to be a bug by me that made the yellow glow lines so thin and feeble. But no matter, it also happened that my clever plan to use only type 5 ldraw lines was not so good. That doesn't actually provide the entire silhouette. So it was back to the drawing board for this one. I gave up on cleverness and implemented the well known stencil buffer silhouette technique. Unfortunately the stencil buffer commands always seem to confuse me, but eventually I connected the right bits in the graphics pipeline and got a decent halo.
I just wish I could convince myself I knew what I was doing. But the sad truth is I don't. You see, I'd really like to have the yellow silhouette showing slightly through the 50% transparent part. But the stencil setting that I thought would do it had no effect. Oh well. Maybe I'll get it eventually by trial and error...
Or maybe not. It just occurred to me that it's not the stencil function blocking the glow inside the faded part, it's the depth buffer blocking all edges inside the faded part. I'll have to try moving the drawing of the glow lines to before the depth buffer writes are done for the faded parts. That just might work.
Anyhow, the final request (so far) was to allow a wider range of color codes that will make these new features more compatible with the calling program LPub3D. I've added some code for that already, but it's not something that provides a spiffy picture.
For posterity, the [feature] thread on the lpub3d issue tracker is issue 47 and it's a really nice example of folks from 4 different projects coming together to collaborate and work out a solution through pictures, dialog, and coding. Good times...
