7:26 p.m.
Long ago, Ted Gould made a proposal on how to do gradient meshes using
elliptic gradients. Sadly this was not workable because gradients are
simply not flexible enough. But now we have blur - and while
approximating a gradient mesh with blurring is still not trivial, it
is possible. See an attached SVG for an example. Of course it's a
nightmare to do all this manually, but as soon as we have code for
bezier intersections, it becomes possible to do an automatic gradient
mesh object using this approach.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:02 p.m.
On Mon, 2006-10-30 at 23:26 -0400, bulia byak wrote:
Long ago, Ted Gould made a proposal on how to do gradient meshes
using
elliptic gradients. Sadly this was not workable because gradients are
simply not flexible enough. But now we have blur - and while
approximating a gradient mesh with blurring is still not trivial, it
is possible. See an attached SVG for an example. Of course it's a
nightmare to do all this manually, but as soon as we have code for
bezier intersections, it becomes possible to do an automatic gradient
mesh object using this approach.
Heh, I was just thinking about this :)
What I'm curious about is the edges. If you look at the attached PNG
what you get is transparent edges, which really isn't what the gradient
specified. I think that the edges have to be backed up with another
object... the question is what.
I'm thinking white. But, I'm not sure that will work correctly when the
vertex has some transparency of it's own. My other thought was a linear
gradient across to the next color on the edge. But, then again, you
have two transparent object effecting something bellow. Perhaps the
alpha could be calculated to compensate?
--Ted
10:30 p.m.
On 10/31/06, Ted Gould <ted@...11...> wrote:
What I'm curious about is the edges. If you look at the attached
PNG
what you get is transparent edges, which really isn't what the gradient
specified. I think that the edges have to be backed up with another
object... the question is what.
See my other mail - we just need to pad the edge segments so they
extend beyond the clip by at least the blur radius. I just tested it
and it works fine, no more transparency at the edges.
With a real mesh with many cells, this only has to be done for the
cells on the edge of the mesh - intercell boundaries inside the mesh
will need no clipping at all, it will be just a continuous field of
fragments.
Another consideration: the size of the fragment must adjust
automatically by taking the _smallest_ cell in the mesh and
subdividing it into a user-settable number of fragments. Then, larger
cells should use the same fragment _size_, not the same number of
subdivisions. This is because we have one single blur radius for the
whole object, and that blur cannot be bigger than the smallest
fragment size.
So, the toughest problem is the subdivision algorithm that would
smoothly and naturally slice up a 4-sided beziergon. Help from
lib2geom gurus will be appreciated :)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:50 p.m.
On Tue, 2006-10-31 at 02:30 -0400, bulia byak wrote:
On 10/31/06, Ted Gould <ted@...11...> wrote:
> What I'm curious about is the edges. If you look at the attached PNG
> what you get is transparent edges, which really isn't what the gradient
> specified. I think that the edges have to be backed up with another
> object... the question is what.
See my other mail - we just need to pad the edge segments so they
extend beyond the clip by at least the blur radius. I just tested it
and it works fine, no more transparency at the edges.
Okay, makes sense.
Another consideration: the size of the fragment must adjust
automatically by taking the _smallest_ cell in the mesh and
subdividing it into a user-settable number of fragments. Then, larger
cells should use the same fragment _size_, not the same number of
subdivisions. This is because we have one single blur radius for the
whole object, and that blur cannot be bigger than the smallest
fragment size.
Instead of a user settable amount of subdivisions shouldn't it be a user
settable amount of error? I'm just thinking that simple meshes would
look good with fewer subdivisions (the majority of cases) but users may
want to set the default division higher to handle all cases. It would
be a shame to over-subdivide, at that point we're basically
rasterizing...
--Ted
3:46 p.m.
On 10/31/06, Ted Gould <ted@...11...> wrote:
Instead of a user settable amount of subdivisions shouldn't it be
a user
settable amount of error?
Yes, or just a unitless "quality level" similar to what we have now for blur.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:58 p.m.
Aren't there potential rendering problems with "bleed-through" along the
edge between abutting beziergons? I know this bites many people using
adjacent gradients to simulate various things.
c.f. bitmap tracing (non-stacked), where the background bleeds through
in the gaps between abutting shapes, even though (mathematically)
there's no gap there.
This is, unfortunately, a property of most antialiasing renderers.
-mental
2:06 a.m.
bulia byak wrote:
Long ago, Ted Gould made a proposal on how to do gradient meshes
using
elliptic gradients. Sadly this was not workable because gradients are
simply not flexible enough. But now we have blur - and while
approximating a gradient mesh with blurring is still not trivial, it
is possible. See an attached SVG for an example. Of course it's a
nightmare to do all this manually, but as soon as we have code for
bezier intersections, it becomes possible to do an automatic gradient
mesh object using this approach.
When I open the file that was attached to this mail
(gradient-mesh-4.svgz), press 1 to zoom in and then scroll downwards to
where the end result is, I get an image like the attached screenshot.
Zooming in or out makes it look right again (as does disabling/enabling
blur).
I'm using the latest exe-only version from inkscape.modevia.com (built
on Oct 20 according to the about box), the selected blur quality doesn't
seem to affect this (I tried average and best and both show the same
problem). I couldn't find any bug report in the tracker about this problem.
Is someone already working on this? (Or is even already fixed?) Or
should I file a bug report?
6240
days inactive
6240
days old
inkscape-devel@lists.inkscape.org
6 comments
4 participants
participants (4)
-
bulia byak -
Jasper van de Gronde -
MenTaLguY -
Ted Gould