2009-06-22 16 views
28

Tengo algunas ilustraciones SVG simples (íconos y glifos) que quiero mostrar en una aplicación OpenGL (desarrollada en C++ en Debian, usando Qt).Visualización de SVG en OpenGL sin ráster intermedio

La solución obvia es utilizar las bibliotecas de ImageMagick para convert SVGs para trazar las imágenes y texturizarlas en algunos polígonos adecuados (o simplemente usar buenas viejas glDrawPixels).

Sin embargo, me pregunto si hay algo que traduzca el SVG directamente a una secuencia de llamadas OpenGL y lo represente utilizando líneas, polígonos y elementos similares de OpenGL. Alguien sabe de algo que puede hacer esto?

+2

hmm .. problema difícil cuando se trata de curvas bezier. Sería bueno ver una solución ya que las dos tecnologías se complementan muy bien. – SpliFF

+1

Esta pregunta se ha realizado de nuevo en http://stackoverflow.com/questions/6287650/rendering-svg-with-opengl-and-opengl-es/ – Fizz

Respuesta

12

Qt puede hacer esto.
QSvgRenderer puede tomar una SVG y pintarlo más de un QGLWidget
Su posiblemente tendrá que ver alrededor de la paintEvent() un poco si desea dibujar cualquier cosa en el QGLWidget que no sea el SVG.

+0

Gracias, muy interesante (debería haberlo notado). No me queda claro a partir de la documentación si el aspecto del vector se conservará por completo en QPainter-on-QGLWidget o si se produce una rasterización intermedia. Sin embargo, debe ser fácil de encontrar usando GLintercept/GLtrace ... – timday

+0

QPainter no suele hacer rasterización alguna. No hay ninguna razón para que comience a hacerlo en el caso de SVG. – shoosh

+0

Después de obtener GLTrace para que funcione con aplicaciones Qt4 en mi plataforma (solución simple, enviada al autor), puedo confirmar que el SVG se está dibujando en el GLWidget usando una cantidad impresionante de llamadas gl *. Trolltech proporciona un buen ejemplo de combinación de mundos 2D y 3D en http://doc.trolltech.com/4.4/opengl-overpainting.html. Lo único que me puedo imaginar queriendo hacer más sería capturar las llamadas de renderizado SVG en una lista de visualización GL (aunque la única razón para hacerlo sería el rendimiento, y si eso se convirtiera en un problema, sería más probable que guardara en caché los mapas de bits renderizados en lugar). – timday

5

SVGL parece abordar esto, pero ha estado inactivo durante varios años. Aún así, es posible que pueda encontrar algún código de valor allí.

+0

El proyecto "sauvage" mencionado por "dru" a continuación parece ser el sucesor. Mismo autor, pero python en lugar de C++. – timday

2

Parece que Inkscape tiene algunas opciones de exportación interesantes que pueden serle útiles. Incluyen DXF, PovRay, EPS, PS (PostScript), XAML, Latex y OpenDocument Drawing (ODG). Tal vez haya un convertidor para uno de esos y podría usar Inkscape como intermediario.

DXF, en particular, es un candidato probable ya que ya es un formato 3D común. assimp es un buen candidato para cargar DXF.

+0

Inkscape aún no tiene una implementación completa de SVG, así que me imagino que sus opciones de exportación también son parciales. – shoosh

+0

Bueno, en realidad todo el SVG que estoy usando se crea en Inkscape de todos modos, por lo que siempre y cuando pueda exportar todo lo suyo ... no hay problema. – timday

+1

Vas a estar más limitado por el formato de salida que SVG de todos modos. DXF tiene más de un millón de años, no va a admitir marcas de corte o degradados complejos. – SpliFF

1

también hay tkzinc como una posibilidad

1

Mi respuesta va a acerca de la visualización de gráficos vectoriales satisfechas con OpenGL en general, porque todas las soluciones para este problema pueden apoyar SVG y no trivial, en particular, aunque el apoyo ninguno SVG animados (SMIL). Como no se dijo nada acerca de la animación, supongo que la pregunta solo implica SVG estáticos.

Desde 2011, el estado del arte es el bebé de Mark Kilgard, NV_path_rendering, que actualmente solo es una extensión de proveedor (Nvidia) como ya habrás adivinado por su nombre. Hay una gran cantidad de material en que:

puede, por IVS carga académica y tal https://www.youtube.com/watch?v=bCrohG6PJQE. También son compatibles con la sintaxis de PostScript para las rutas.También se puede mezclar ruta de reproducción con otras cosas OpenGL (3D), que hizo una demostración en:

NV_path_rendering ahora es utilizado por la biblioteca Skia de Google detrás de las escenas, cuando esté disponible. (Nvidia contribuyó con el código a finales de 2013 y 2014). A uno de los desarrolladores de cairo (que también es empleado de Intel) parece gustarle también http://lists.cairographics.org/archives/cairo/2013-March/024134.html, aunque todavía no conozco ningún esfuerzo concreto para que el cairo lo use. NV_path_rendering.

Un advenedizo que tiene incluso menos (o francamente sin) soporte de proveedor o brillo académico es NanoVG, que actualmente está desarrollado y mantenido. (https://github.com/memononen/nanovg) Dada la cantidad de librerías en 2D sobre OpenGL que han ido y venido en el tiempo, usted está haciendo una gran apuesta usando algo que no es respaldado por un proveedor importante, en mi humilde opinión.

Cuestiones relacionadas