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
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?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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).
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 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
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
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
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
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
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
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
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
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
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/
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
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.
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
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
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
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
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
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