[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [freesci-develop] OpenGL picmap renderer
From: |
Christoph Reichenbach |
Subject: |
Re: [freesci-develop] OpenGL picmap renderer |
Date: |
Mon, 21 Nov 2005 18:04:14 -0700 |
User-agent: |
Mutt/1.5.4i |
Jim,
On Mon, Nov 21, 2005 at 04:01:07PM -0500, James Albert wrote:
> I have svg files, but my svg renderer is broken right now (new firefox
> beta), so I have no idea what they look like. I haven't touched the
> code for months.
Hm. Can anyone help out here? It would be very interesting to see what this
looks like?
> - The classic approach requires direct pixel manipulation. Even a
> scaled version needs some kind of pixel testing in order to do the
> boundaries and gaps correctly.
We currently maintain a scaled and an unscaled image to do this (this is
noticeable if you use the kernel call 'Show()' to switch to the priority map:
You will then be shown a 320x190 priority map, even if you're using scaled
background images, though it is evident that the visual map employs a more
accurate scheme).
> - The vector approach is *entirely* mathematical. There's no actual
> pixel buffer, so there's no way to do pixel testing, because there are
> no pixels.
Well, matrices are mathematical constructions, too... ;-)
> My best solution so far (and the one I'm currently using), is to render
> both the vector and classical versions at the same time in a sort of
> hybrid approach.
Makes sense...
[...]
> Basically I render the pic as usual, but I also store the geometry
> data. This way, when I do a fill it can look at what the output is
> supposed to be and go "oh, I shouldn't fill here" without resorting to
> really complex vector mathematics. The problem I'm having here is
> coming up with a hybrid flood fill/triangulation algorithm - if that
> even makes sense.
I'm not sure if I see all of the issue here, but rest assured that I believe
you if you say that it's not easy ;-)
[...]
I'm afraid that I can't offer any advice on these issues at the moment.
> So basically, it has potential, and it's a safer and more
> straightforward method then dealing with image scaling, but it still
> needs a lot of work.
Sounds good! I completely agree that translating from the flood-filled world
to the world of vector graphics is much preferrable, for many reasons (it also
allows us to do a few more tricks with rendering the picture
afterwards). In particular, we can use this approach for pic rendering
independently of an OpenGL graphics driver.
-- Christoph