Scientific computing with D

[Bill Baxter]

On Sat, Jan 31, 2009 at 9:14 AM, Chad J
<gamerchad at __spam.is.bad__gmail.com> wrote:
> Bill Baxter wrote:
>>>
>>> As it's somewhat related, I'll mention that I'm working on a library in
>>> D that renders svg images using OpenGL.  It can currently trace lines,
>>> rectangles, and circles, and more or less understands svg's nesting
>>> hierarchy and mathematical transformations.  I'll try to finish off all
>>> of the filling, blending, stroking, and such things this Spring quarter.
>>>  The license will be something liberal (zlib/freebsd/etc).
>>
>> Nice.  I wrote something to do the opposite :-)  To go from OpenGL to
>> an SVG file.
>> Actually I just cobbled together a couple of existing projects OGLE
>> (non-intrusive OpenGL32.dll replacement that can output jpegs and
>> wavefront .objs ) and gl2ps (intrusive API for outputing GL to
>> PS/SVG/etc) -- resulting in a non-intrusive solution for capturing GL
>> output to an SVG.   Been using that heavily to make figures for papers
>> lately.
>>
>
> Huh.  That sounds rather impressive and useful.
>
>> I haven't actually made the code available anywhere... should do that
>> eventually.
>>
>> Back to your project, how are you handling A) filled polygons
>> (gluTess?)   B) antialiasing?
>>
>
> A.) Hand rolled tessellation (working on it, actually getting a bit
> distracted by it since it's an interesting problem and fun to play with.)
> B.) Antialiasing - let OpenGL handle it.
>
>> Some day I'd love to try to port AGG to D.  I bet its possible to make
>> some really slick and elegant improvements to AGG given D's templates.
>>
>> --bb
>
> Ah AGG.  Looked good, though I didn't use it because of the GPL in 2.5
> (semi-maintained-maybe branch) and because I tend to avoid things that
> aren't maintained (2.4 branch).  Oh and yeah wrapping C++ isn't fun.
>
> Maybe port the 2.4?  ;)

Yeh definintely.  I'm not even going to look at the 2.5 GPL version.
And wrapping that is just out of the question.  Well, you could but I
don't see the point when D's templates are so rockin.

As for stagnation, the 2.4 version is actually very mature.  The
mailing list is still pretty active, and some folks are maintaining it
over on SourceForge, I think.   Anyway, it seems Mr. AGG himself isn't
really working on AGG either, these days since he got a job where he
gets paid to do similar stuff.  Probably not enough time, and too much
legal murkiness about his work product vs. his free time effort.
There was just a big debate on the AGG mailing list yesterday where
people were saying AGG is withering away, and half dozen people sprang
up to say it wasn't dead it just works fine and doesn't need much
maintenance.

So that's a pretty ideal situation for porting to D.  If it's pretty
much a finished lib, then there won't even be much in the way of
headaches merging in new updates.  Since there probably won't be many.

Anyway, antiailiasing of AGG looks very nice.  :-)   I did my previous
(C++) project using AGG for rendering.  But this time I just decided
to go with GL.  GL is way easier to work with, but I do miss the
quality of AGG rendering.  MSAA/FSAA just can't hold a candle to
genuine primitive-level antialiasing (2~16 gradations vs 256).

Still, most of us have pretty decent graphics hardware on our desks
these days.  It's sad that we still can't really use it to get decent
quality 2D graphics.  So really I think the future is not AGG but some
clever shaders to do AA with graphics hardware.  I think DX10 class
hardware opens up new possibilities here.  And probably the distant
distant future is back to just brute force 256x oversampling :-)

--bb