SVG path to vertices / indices array?

[Nicolas Garcia Belmonte]

Do you know of some lib or algorithm to transform an SVG path into a set of vertices / indices / faces to work with WebGL?

[Catalin]

I think I saw in the past a blender python script .
I don't remember where . Try : http://blenderartists.org/forum/forum.php

2012/12/21 Nicolas Garcia Belmonte <phi...@gmail.com>

Do you know of some lib or algorithm to transform an SVG path into a set of vertices / indices / faces to work with WebGL?

--
python-catalin.blogspot.com
www.free-tutorials.org

[Mark Callow]

On 2012/12/21 7:12, Nicolas Garcia Belmonte wrote:

Do you know of some lib or algorithm to transform an SVG path into a set of vertices / indices / faces to work with WebGL?

Check out the NV_path_rendering extension or more precisely the paper about it published at Siggraph Asia 2012. The paper's references list several papers describing the various techniques. Note, the extension is for native OpenGL and is currently only available in NVIDIA drivers (version > 300 recommended for very high performance).

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

[Benoit Jacob]

That is actually a reasonable thing to propose adding as a WebGL extension because:
 - it is relatively hard to do yourself in application code (implementing SVG is hard)
 - browsers already have a SVG implementation anyways.

You could send an email to public_webgl about that if you care.

Benoit

2012/12/20 Nicolas Garcia Belmonte <phi...@gmail.com>

[Mark Callow]

On 2012/12/27 0:26, Benoit Jacob wrote:

That is actually a reasonable thing to propose adding as a WebGL extension because:
 - it is relatively hard to do yourself in application code (implementing SVG is hard)
 - browsers already have a SVG implementation anyways.

You could send an email to public_webgl about that if you care.

Converting SVG paths to triangles is probably not the best approach. For one thing maintaining smooth curves requires re-tesselation when the scale changes.  Again I refer you to the paper about the NV_path_rendering extension. I firmly believe its stencil then cover approach is the right way to get accurate and numerically stable results regardless of path complexity.

[Gregg Tavares (社用)]

I definitely do not agree that putting this functionality into the browser is a good idea.

There are thousands of ways to do it. Each with trade offs. Solutions that fit one use case won't fit others.

Write some JS libraries, let percolate for 5-10 years, then see if something really emerges as needed.

A quick search brings up these possible starting points

http://code.google.com/p/canvg/

http://stackoverflow.com/questions/10717190/convert-svg-polygon-to-path

http://readysetraphael.com/

I'm sure there's more.

[Tony Parisi]

I'm with Gregg, for my own reasons.

Why in the world would we expect browsers to implement SVG on top of WebGL when they don't even implement a real 3D format natively yet? e.g. X3D or whatever. That makes no sense to me. The philosophy with WebGL thus far has been to provide rendering and compositing capability, and leave formats and engines to be implemented at the JavaScript level. Whether I agree with it philosophically or not, the approach seems to be working so far so why mess with it?

While I myself would love to see some kind of basic 3D "scene graph" or other high level data format implemented natively (my VRML prejudice showing here), for the moment I'm OK with having to deal with it at the app level, and I would object strenuously to any data formats getting preferential treatment, especially non-3D ones.

Tony

--
Tony Parisi                             tpa...@gmail.com
CTO at Large                         415.902.8002
Skype                                     auradeluxe
Follow me on Twitter!             http://twitter.com/auradeluxe
Read my blog at                     http://www.tonyparisi.com/

Read my book! WebGL, Up and Running
http://shop.oreilly.com/product/0636920024729.do
http://www.amazon.com/dp/144932357X

[Mark Callow]

On 2012/12/27 13:01, Tony Parisi wrote:

I'm with Gregg, for my own reasons.

Why in the world would we expect browsers to implement SVG on top of WebGL when they don't even implement a real 3D format natively yet?

Having the browsers implement SVG on top of WebGL is indeed the wrong way around. If something like NV_path_rendering were to become widespread in OpenGL implementations then the browsers could implement their entire graphics stack on OpenGL with beautiful and fast results. Then WebGL would merely need to expose the underlying path functions.

Furthermore the true integration of 2D vector graphics and 3D graphics enabled by this technology would open up many interesting possibilities for web applications and browsers. Web "pages" would probably become something of a misnomer.

...

While I myself would love to see some kind of basic 3D "scene graph" or other high level data format implemented natively (my VRML prejudice showing here), for the moment I'm OK with having to deal with it at the app level, and I would object strenuously to any data formats getting preferential treatment, especially non-3D ones.

NV_path_rendering provides path primitives corresponding to SVG, PostScript and OpenVG path commands. It does not support a data format in the sense of SVG or X3D.

Attached are 2 images of our corporate web page rendered entirely on the GPU with NV_path_rendering. The first shows the entire page, the second is a zoom-in on part of it. Note, I reduced the images to 50% of their original size, to keep the size of this message down, which may have introduced some artefacts. The originals are completely artefact free.