9:28 a.m.
Hi,
Are we still waiting for the SVG standards before we can implement gradient
meshes ?
I have a ( pretty simple and obvious ) method of rendering gradient meshes
that is simpler than blurring multiple beziergons and is quite fast ( 100 ms
in Java rendering 500x500px approx ), I was wondering if we start putting a
basic gradient mesh in inkscape and we can conform/export to the SVG format
when it comes out.
I believe we are trying to get a triangle gradient primitive approved from
SVG. Do we have any plans of getting a quadrilateral primitive ? It will be
more accurate for gradient mesh. This paper I found explains some
quadrilateral rendering techniques :
http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf
Thanks
-Sid
10:33 p.m.
On Mon, Dec 21, 2009 at 9:28 PM, sid datta <datta.sid@...400...> wrote:
...
I believe we are trying to get a triangle gradient primitive approved from
SVG.
Hi Sid,
I did not find any reference for "triangle gradient svg site:w3.org" on google.
I also try "barycentric svg site:w3.org". There is some debate about this?
Do we have any plans of getting a quadrilateral primitive ? It will
be
more accurate for gradient mesh. This paper I found explains some
quadrilateral rendering techniques :
http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf
That is very interesting! That is possible to use a filter to enable this
before the W3C specification?
--
Aurélio A. Heckert http://colivre.coop.br/Aurium
GNU/Linux User #312507 http://counter.li.org
- - - - - - - - - - - - - - - - - - - - - - - - -
Ilustração Vetorial Livre: http://InkscapeBrasil.org
Coop. de Tecnologias Livres: http://Colivre.coop.br
- - - - - - - - - - - - - - - - - - - - - - - - -
"Windows 7: a new era of restrictions."
http://windows7sins.org
Antes de imprimir esta mensagem reflita
sobre a sua responsabilidade com a
preservação do Meio Ambiente.
5:01 a.m.
None of this is part of inkscape now.
I am trying to figure out if the developers will approve if I try to add
these in inkscape.
On Tue, Dec 22, 2009 at 5:33 AM, Aurélio A. Heckert <aurium@...400...>wrote:
On Mon, Dec 21, 2009 at 9:28 PM, sid datta
<datta.sid@...400...> wrote:
> ...
> I believe we are trying to get a triangle gradient primitive approved
from
> SVG.
Hi Sid,
I did not find any reference for "triangle gradient svg site:w3.org" on
google.
I also try "barycentric svg site:w3.org". There is some debate about this?
> Do we have any plans of getting a quadrilateral primitive ? It will be
> more accurate for gradient mesh. This paper I found explains some
> quadrilateral rendering techniques :
> http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf
That is very interesting! That is possible to use a filter to enable this
before the W3C specification?
--
Aurélio A. Heckert http://colivre.coop.br/Aurium
GNU/Linux <http://colivre.coop.br/Aurium%0AGNU/Linux> User #312507
http://counter.li.org
- - - - - - - - - - - - - - - - - - - - - - - - -
Ilustração Vetorial Livre: http://InkscapeBrasil.org
Coop. de Tecnologias Livres: http://Colivre.coop.br
- - - - - - - - - - - - - - - - - - - - - - - - -
"Windows 7: a new era of restrictions."
http://windows7sins.org
Antes de imprimir esta mensagem reflita
sobre a sua responsabilidade com a
preservação do Meio Ambiente.
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
8:13 p.m.
sid datta wrote:
None of this is part of inkscape now.
I am trying to figure out if the developers will approve if I try to add
these in inkscape.
In general, if it's not part of SVG and there is no fall back, then no.
It might be possible to develop a fall back however, and I'd be
perfectly willing to help if you'd like (I also looked into simulating
radial gradients with SVG for example).
BTW, have you ever had a look at diffusion curves? That would be my
personal favorite to add to Inkscape (instead of or in addition to
gradient meshes).
10:21 p.m.
Hello,
In general, if it's not part of SVG and there is no fall back,
then no.
Wouldn't it be a good idea to (first) work out a specification of
gradient meshes for the W3C SVG WG? Looking through the archives it
seems to me as if they didn't even yet agree on the general topology...
PDF (and PS level 3) for example knows these gradient types:
• Function-based shadings (type 1) define the color of every point in
the domain
using a mathematical function (not necessarily smooth or continuous).
• Axial shadings (type 2) define a color blend along a line between two points,
optionally extended beyond the boundary points by continuing the boundary
colors.
• Radial shadings (type 3) define a blend between two circles, optionally ex-
tended beyond the boundary circles by continuing the boundary colors. This
type of shading is commonly used to represent three-dimensional spheres and
cones.
• Free-form Gouraud-shaded triangle meshes (type 4) define a common construct
used by many three-dimensional applications to represent complex colored
and shaded shapes. Vertices are specified in free-form geometry.
• Lattice-form Gouraud-shaded triangle meshes (type 5) are based on the same
geometrical construct as type 4 but with vertices specified as a pseudo-
rectangular lattice.
• Coons patch meshes (type 6) construct a shading from one or more color
patches, each bounded by four cubic Bézier curves.
• Tensor-product patch meshes (type 7) are similar to type 6 but with additional
control points in each patch, affording greater control over color mapping.
(http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf pg. 304)
AFAIK SVG only has "Type 2" gradients, since PDF's "Type 3" allows
not
only ellipses and their center but arbitrary circles.
"Type 7" Tensor-product patch meshes seem like the best format to me,
depending on the output format it can be rendered as types 6, 5, 4, or
blurred blobs of color.
The UI should be like Illustrator's, i.e. allow generation of a
rectangular n*m grid, subdivision, and the gravity brushes to deform the
mesh. Also, in addition to pulling on path segments using the mouse and
thereby adjusting the 2 control points, it should be possible to pull on
a patch and adjust its 8 control points.
Just my 2ct.
--
pascal
11:14 p.m.
Pascal Germroth wrote:
AFAIK SVG only has "Type 2" gradients, since PDF's
"Type 3" allows not
only ellipses and their center but arbitrary circles.
"Type 7" Tensor-product patch meshes seem like the best format to me,
depending on the output format it can be rendered as types 6, 5, 4, or
blurred blobs of color.
The UI should be like Illustrator's, i.e. allow generation of a
rectangular n*m grid, subdivision, and the gravity brushes to deform the
mesh. Also, in addition to pulling on path segments using the mouse and
thereby adjusting the 2 control points, it should be possible to pull on
a patch and adjust its 8 control points.
Note: I'm repeating things I have read but I have not experience or
knowledge about the matter myself.
Color in SVG includes an alpha channel. I've been told that rendering of
Coons patch meshes is ambiguous when this is the case. Does this also
affect Tensor-product patch meshes?
In the past some people were of the opinion that common UIs for editing
Coons patch meshes were complicated and unintuitive for artists. The
hope was to develop something more natural to work with.
Aaron Spike
11:55 p.m.
On Thu, Dec 24, 2009 at 5:14 PM, Aaron Spike wrote:
In the past some people were of the opinion that common UIs for
editing
Coons patch meshes were complicated and unintuitive for artists. The
hope was to develop something more natural to work with.
Do you think you could come up with a list of characteristics of a
more natural approach?
Alexandre
12:47 a.m.
On Thu, 24 Dec 2009 17:55:27 +0300
Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Thu, Dec 24, 2009 at 5:14 PM, Aaron Spike wrote:
> In the past some people were of the opinion that common UIs for editing
> Coons patch meshes were complicated and unintuitive for artists. The
> hope was to develop something more natural to work with.
Do you think you could come up with a list of characteristics of a
more natural approach?
Blender, the open source 3D animation package, lets you "paint" color onto
meshes, where the color you're painting modifies the color assigned to to the
surrounding vertices based on how close the pointer is to the vertices. Very much like
the Tweak tool does in color painting mode - almost identical, really :-)
Cheers -Terry
1:35 a.m.
Alexandre Prokoudine wrote:
On Thu, Dec 24, 2009 at 5:14 PM, Aaron Spike wrote:
> In the past some people were of the opinion that common UIs for editing
> Coons patch meshes were complicated and unintuitive for artists. The
> hope was to develop something more natural to work with.
Do you think you could come up with a list of characteristics of a
more natural approach?
Note: I'm repeating things I have read but I have not experience
or
knowledge about the matter myself.
No, I cannot. I was only repeating what I remember from previous threads.
Aaron Spike
2:56 a.m.
On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
Note: I'm repeating things I have read but I have not experience
or
knowledge about the matter myself.
Noted.
Color in SVG includes an alpha channel. I've been told that
rendering of
Coons patch meshes is ambiguous when this is the case. Does this also
affect Tensor-product patch meshes?
I'm curious about the ambiguity. Do you recall why that was said? I'm
sure it's more technical, but if it works how I imagine it could, it
could afford great artistic leverage.
In the past some people were of the opinion that common UIs for
editing
Coons patch meshes were complicated and unintuitive for artists. The
hope was to develop something more natural to work with.
I think that the AI method for editing them (the only one I'm familiar
with) is okay, not great or even good though. Then again, I feel the
same about their path/node handling tools. I think that with what I've
seen of things like our node tool and the tweak tool (and engraver stuff
for the calligraphy tool)... well, bulia would find a way to at
significantly make it more artist friendly (not to sign you up for
anything bulia).
I will comment though, thanks to the numerous 3D packages and their
various mesh editing/painting techniques, we have some nice ideas to
borrow from if desired. Unlike other vector apps, since we don't have
meshes yet, we just happen to have the advantage of not being stuck with
an old design that we can't change for fear of rocking the boat. :)
Cheers,
Josh
7:10 a.m.
Joshua A. Andler wrote:
On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
> Color in SVG includes an alpha channel. I've been told that rendering of
> Coons patch meshes is ambiguous when this is the case. Does this also
> affect Tensor-product patch meshes?
I'm curious about the ambiguity. Do you recall why that was said? I'm
sure it's more technical, but if it works how I imagine it could, it
could afford great artistic leverage.
IIRC extreme bends in the control beziers can cause the fill to self
overlap. Transparent or semi-transparent colors would allow the deeper
parts of the fill to bleed through. And once again, remember that I
don't know what I'm talking about. :-)
Aaron Spike
7:20 a.m.
On 12/25/09, Aaron Spike wrote:
IIRC extreme bends in the control beziers can cause the fill to self
overlap. Transparent or semi-transparent colors would allow the deeper
parts of the fill to bleed through. And once again, remember that I
don't know what I'm talking about. :-)
I believe mentalguy used to know quite a lot about this. Not sure if
he's reading the list though. Anyway, SVG 2.0 FPWD is scheduled for
April 2010, and if we come up with a well thought proposal, we might
try to work around the chicken-egg situation with SVG features we
want. What do you guys and girls think?
Alexandre
7:37 a.m.
On Fri, 2009-12-25 at 01:20 +0300, Alexandre Prokoudine wrote:
On 12/25/09, Aaron Spike wrote:
> IIRC extreme bends in the control beziers can cause the fill to self
> overlap. Transparent or semi-transparent colors would allow the deeper
> parts of the fill to bleed through. And once again, remember that I
> don't know what I'm talking about. :-)
I believe mentalguy used to know quite a lot about this. Not sure if
he's reading the list though. Anyway, SVG 2.0 FPWD is scheduled for
April 2010, and if we come up with a well thought proposal, we might
try to work around the chicken-egg situation with SVG features we
want. What do you guys and girls think?
Yes, from my understanding Mental knows more than anyone else in our
camp when it came to the issues. I think it's a great idea Alexandre.
Mental, what do you think? Perhaps as a group we can figure out some
solutions or alternative ideas?
Cheers,
Josh
7:41 a.m.
On Thu, 2009-12-24 at 16:10 -0600, Aaron Spike wrote:
Joshua A. Andler wrote:
> On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
>> Color in SVG includes an alpha channel. I've been told that rendering of
>> Coons patch meshes is ambiguous when this is the case. Does this also
>> affect Tensor-product patch meshes?
>
> I'm curious about the ambiguity. Do you recall why that was said? I'm
> sure it's more technical, but if it works how I imagine it could, it
> could afford great artistic leverage.
IIRC extreme bends in the control beziers can cause the fill to self
overlap. Transparent or semi-transparent colors would allow the deeper
parts of the fill to bleed through. And once again, remember that I
don't know what I'm talking about. :-)
I could see artistic benefits to bleeding through... realistic looking
cellophane or non-opaque fabrics for example. Then again as you
described, I could see the drawbacks too... unless there was something
like the equivalent of "fill-rule" for meshes, so it is optional to
render the deeper parts.
Cheers,
Josh
8:37 a.m.
Aaron Spike wrote:
Joshua A. Andler wrote:
> On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
>> Color in SVG includes an alpha channel. I've been told that rendering of
>> Coons patch meshes is ambiguous when this is the case. Does this also
>> affect Tensor-product patch meshes?
> I'm curious about the ambiguity. Do you recall why that was said? I'm
> sure it's more technical, but if it works how I imagine it could, it
> could afford great artistic leverage.
IIRC extreme bends in the control beziers can cause the fill to self
overlap. Transparent or semi-transparent colors would allow the deeper
parts of the fill to bleed through. And once again, remember that I
don't know what I'm talking about. :-)
There is an experimental implementation of mesh gradients for cairo at:
http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=mesh
This branch makes it easy to write a few test cases help understand how
PDF Type 6 and 7 gradients work.
Some sample output (including self overlapping and transparency) is at:
http://people.freedesktop.org/~ajohnson/mesh/
8:52 a.m.
On Fri, 2009-12-25 at 10:07 +1030, Adrian Johnson wrote:
Aaron Spike wrote:
> Joshua A. Andler wrote:
>> On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
>>> Color in SVG includes an alpha channel. I've been told that rendering
of
>>> Coons patch meshes is ambiguous when this is the case. Does this also
>>> affect Tensor-product patch meshes?
>> I'm curious about the ambiguity. Do you recall why that was said? I'm
>> sure it's more technical, but if it works how I imagine it could, it
>> could afford great artistic leverage.
>
> IIRC extreme bends in the control beziers can cause the fill to self
> overlap. Transparent or semi-transparent colors would allow the deeper
> parts of the fill to bleed through. And once again, remember that I
> don't know what I'm talking about. :-)
There is an experimental implementation of mesh gradients for cairo at:
http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=mesh
This branch makes it easy to write a few test cases help understand how
PDF Type 6 and 7 gradients work.
Some sample output (including self overlapping and transparency) is at:
http://people.freedesktop.org/~ajohnson/mesh/
Would you be willing to do one that has both self-overlapping &
transparency where the overlapping portions are? I'm not seeing one
currently. That would be helpful to seeing how it reacts.
Cheers,
Josh
9:24 a.m.
Joshua A. Andler wrote:
On Fri, 2009-12-25 at 10:07 +1030, Adrian Johnson wrote:
> Aaron Spike wrote:
>> Joshua A. Andler wrote:
>>> On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
>>>> Color in SVG includes an alpha channel. I've been told that rendering
of
>>>> Coons patch meshes is ambiguous when this is the case. Does this also
>>>> affect Tensor-product patch meshes?
>>> I'm curious about the ambiguity. Do you recall why that was said?
I'm
>>> sure it's more technical, but if it works how I imagine it could, it
>>> could afford great artistic leverage.
>> IIRC extreme bends in the control beziers can cause the fill to self
>> overlap. Transparent or semi-transparent colors would allow the deeper
>> parts of the fill to bleed through. And once again, remember that I
>> don't know what I'm talking about. :-)
> There is an experimental implementation of mesh gradients for cairo at:
> http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=mesh
>
> This branch makes it easy to write a few test cases help understand how
> PDF Type 6 and 7 gradients work.
>
> Some sample output (including self overlapping and transparency) is at:
> http://people.freedesktop.org/~ajohnson/mesh/
>
Would you be willing to do one that has both self-overlapping &
transparency where the overlapping portions are? I'm not seeing one
currently. That would be helpful to seeing how it reacts.
Cheers,
Josh
I've added the mesh-gradient-overlap-transp test case.
9:49 a.m.
On Fri, 2009-12-25 at 10:54 +1030, Adrian Johnson wrote:
Joshua A. Andler wrote:
> On Fri, 2009-12-25 at 10:07 +1030, Adrian Johnson wrote:
>> Aaron Spike wrote:
>>> Joshua A. Andler wrote:
>>>> On Thu, 2009-12-24 at 08:14 -0600, Aaron Spike wrote:
>>>>> Color in SVG includes an alpha channel. I've been told that
rendering of
>>>>> Coons patch meshes is ambiguous when this is the case. Does this
also
>>>>> affect Tensor-product patch meshes?
>>>> I'm curious about the ambiguity. Do you recall why that was said?
I'm
>>>> sure it's more technical, but if it works how I imagine it could,
it
>>>> could afford great artistic leverage.
>>> IIRC extreme bends in the control beziers can cause the fill to self
>>> overlap. Transparent or semi-transparent colors would allow the deeper
>>> parts of the fill to bleed through. And once again, remember that I
>>> don't know what I'm talking about. :-)
>> There is an experimental implementation of mesh gradients for cairo at:
>> http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=mesh
>>
>> This branch makes it easy to write a few test cases help understand how
>> PDF Type 6 and 7 gradients work.
>>
>> Some sample output (including self overlapping and transparency) is at:
>> http://people.freedesktop.org/~ajohnson/mesh/
>>
>
> Would you be willing to do one that has both self-overlapping &
> transparency where the overlapping portions are? I'm not seeing one
> currently. That would be helpful to seeing how it reacts.
>
> Cheers,
> Josh
I've added the mesh-gradient-overlap-transp test case.
Thanks! Out of curiosity, are there any plans for integration into head
any time in the "near" future or are is there a need for more testing? I
think i will give it a compile in the next couple weeks to play with it
a little.
Cheers,
Josh
10:44 a.m.
If you think about it , the blender painting tool, implemented in inkscape,
would be exactly like a bitmap editing feature. Nodes would be like pixels.
I am assuming a rectangular grid here, I am not sure what will be the
usecase of other kinds of grids while painting.
I am not completely disavowing painting, I think there is lots of potential
in the painting idea :).
I think if the gradient mesh can interact with the tweak tool it will give
artists some interesting options.
We should definitely push for Types 3, 4 and 5. ( Hopefully a quadrilateral
gradient too ? as per paper
http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf ).
We should also push for types 6 and 7, if possible after figuring out an
unique way to disambiguate things ( colors always show through ? )
BTW, does SVG have an "extension" system where an application can put its
own data, that is outside the standard and other applications might not
understand ? That can be another way of putting our own stuff in before SVG
approves it.
Thanks
-Sid
11:20 a.m.
sid datta wrote:
BTW, does SVG have an "extension" system where an
application can put
its own data, that is outside the standard and other applications might
not understand ? That can be another way of putting our own stuff in
before SVG approves it.
SVG does have an "extension" system. SVG is an application of XML. The X
stands for extensible. And Inkscape extends SVG all over the place. You
can see the difference when saving Inkscape SVG or Plain SVG. Or rather,
you shouldn't see the difference unless you look at the XML markup
inside the file. We've made a pact that our extensions to SVG shouldn't
change how the file is rendered in other viewers. Our SVG extensions
store many sorts of metadata to help Inkscape edit the files but not
different objects to render. (With the regrettable exception of FlowText.)
Aaron Spike
12:42 p.m.
On Thu, Dec 24, 2009 at 6:20 PM, Aaron Spike <aaron@...749...> wrote:
sid datta wrote:
Our SVG extensions
store many sorts of metadata to help Inkscape edit the files but not
different objects to render. (With the regrettable exception of FlowText.)
Aaron Spike
Ahhhh, I see. So I guess if we put the gradient meshes in the extension part
it would also be regrettable ? :)
Would you guys be ok with it if this stuff ( gradient types 3 to 7 ) goes
in the extension part ?
Thanks
-Sid
1:58 a.m.
On 12/25/09, Adrian Johnson wrote:
There is an experimental implementation of mesh gradients for cairo
at:
http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=mesh
And now Scribus 1.5.0svn supports creating gradient meshes and reading
them from Adobe Illustrator documents thanks to this branch.
Alexandre
4771
days inactive
4917
days old
inkscape-devel@lists.inkscape.org
21 comments
9 participants
participants (9)
-
Aaron Spike -
Adrian Johnson -
Alexandre Prokoudine -
Aurélio A. Heckert -
Jasper van de Gronde -
Joshua A. Andler -
Pascal Germroth -
sid datta -
Terry Brown