freesci-develop
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]