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.
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
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 :)
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
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.
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
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?
participants (4)
-
bulia byak -
Jasper van de Gronde -
MenTaLguY -
Ted Gould