Does libGDX support rendering vector graphics? I need to draw some simple *.svg files, but can't find how to load them. Please advise
Nope it does not.
LibGDX provides you a way to draw simple shapes (implemented as ShapeRenderer) but it cannot parse .svg probably due to being multiplatform.
Still you can use some 3rd part library designed for specify platform like svg android
Also take a look at this:
Thread #1
Thread #2
Related
I have been tearing my hair out for a while over this. I need an OpenGL 3.2 Core (no deprecated stuff!) way to efficiently render many sprites, using batching (no instancing).
I've seen examples that do this with geometry alone, but mine also needs to send textures to it, I don't know how to do this.
I need a well done example of it working in action. And looking at how other libs like monogame and such do it isn't much help, because all I'm interested in is the GL code, and it has to have no deprecated stuff in it.
Basically I want to be able to efficiently render thousands+ of sprites, all having textures. The texture is just a spritesheet, so I just need to tell it to render a region of that spritesheet.
I'm disappointed in the amount of material available for programmable pipeline. To the point where it seems like it'd be so much easier to just say screw it and use fixed pipeline, even though I definitely don't want to do that.
So yeah, any full examples that do what I want? Or could somebody more knowledgable write one up? :)
A lot of the examples are "oh, here's how you render 1 triangle". Well that's great, except nobody needs to render only 1 triangle/quad. And they need to be textured in addition to that!
An example that uses VBOs/VAOs/EBOs
ALSO: this means the code can't use glTexPointer and that stuff, but just in raw VBOs/VAOs...
I saw this question and decided to write a little program that does some "sprite" rendering using points and gl_PointSize. I'm not quite sure what you mean by "batching" as opposed to "instancing," but my program uses the glDrawArraysInstanced() call so that I can render multiple points without needing my VBO to be variable sized. My code also doesn't texture the sprites, but that's easy enough to add in (upload the active texture index (the one that was active during your call to glTexSubImage), to a GLSL sampler2D using glUniform1i).
Anyway, here's the program I wrote: http://litherum.blogspot.com/2013/02/sprites-in-opengl-programmable-pipeline.html Hope you can learn from it!
I like the idea of Nodebox and Processing, and would like to generate movies to visualize some data/algorithms. However, Nodebox exports extremely bloated Quicktime files with frame by frame images, and Processing only exports Java applications. I want to be able to export movies that don't take a Gigabyte a minute of disk space. Perhaps something like SVG animations or Actionscript which stores the vector graphics definition of the animation rather than frame images would be better. Is there a framework that is as easy to program as Nodebox and Processing and can export "lean" movies?
Have you tried the MovieMaker library that ships with Processing ?
Also, it should be fairly simple to save multiple frames using saveFrame().
This is option have a couple of advantages:
If your sketch crashes at some point, you still have all the frames up to that point (unlike writing a .mov file)
It's fairly simple to put the frames back into a video file, but you also have control over playback speed and can easily do a bit of editing if needed.
You can try to a sequence of PDF file using createGraphics() to get vector output, but I'm not sure how stable/feasible this option is.
They are changing the way this works moving towards 2.0 too, as they are moving to GSVideo over Quicktime...
Daniel Shiffman posted about it recently on his blog, but it's the only place I've heard about any changes to post-2.0 tactics (though he IS part of the inner circle, I know)
You can find that post at
http://www.shiffman.net/2011/12/28/night-8-rendering-out-as-image-sequence/
Also, if you are on OSX, you can try Syphon ? See info here
https://forum.processing.org/topic/syphon-integration-with-processing
I'm looking at some older code which is rendering some images, animations, etc... for a website by generating a web page containing significant SVG elements. The result is a fairly complicated, interactive, interface. I've been tasked with migrating the application to instead generate WebGL calls.
This is a non-trivial task, considering all of the niceties that come with SVG, which are not directly available if going straight to a WebGL implementation. I've been debating whether I should pitch migrating to using something like Three.js instead, but don't know enough about the available options to make a good decision.
What are some reasonable options I should consider when trying to build my battle plan here?
I would suggest you look at http://code.google.com/p/canvg/ as an option.
I assume it is using getContext("2d") not getContext("experimental-webgl") or getContext("webgl").
WebGL provides a 3d interface and I am not sure if there is any advantage to using it for 2d graphics, since you don't have any 3d transforms for the GPU to work on. If they are interested in Canvas not specifically webgl ... Canvg would bring over some of the niceties of SVG which would be the source content.
If the issue is lack of support for SVG in browsers http://code.google.com/p/svgweb/ goes a long way to solving that problem.
I read while Googling that SVG was "dead". Although I disagree, could anyone tell me more/future vector based format to represent 2d/3d graphics? What about VML? What format should I use to represent 2D and 3D graphics on Web?
I playing around with graphics on web and I would like to know if I'm working with an obsolete technology.
Microsoft is supporting SVG in IE9, and gave a detailed explanation of why they were doing it on the IE blog:
http://blogs.msdn.com/b/ie/archive/2010/03/18/svg-in-ie9-roadmap.aspx
SVG's main advantage is that it becomes part of the DOM, so you can use CSS to style it and javascript to modify it. Canvas, by contrast, must redraw every frame completely. This makes canvas suited to spectrum analyzers, video processing, fast-paced games, and other non-gradual animations. SVG is better suited for gradual animations.
As far as 3D is concerned, the future is WebGL, a thin shim over OpenGL ES, but it's far off. Microsoft has not committed to supporting it, and that means it's not going to be in IE9. Maybe IE10, maybe not.
If you do use SVG, I recommend using svgweb to abstract away the browser differences (falls back to a flash applet on outdated browsers).
This post is rather late... but I think it is worth re-addressing, since your question has popped up again with all the html5 talk.
SVG is a vector drawing format that also supports animation, timing, and Javascript DOM support. In other words, it is a standalone format for static and dynamic vector graphics; you might say it is a web-focused (or screen-focused) alternative to EPS/PDF. The html5 canvas tag is not a format but a way to draw (static images) to the screen with Javascript — that is all; there is no competition between it and SVG, as they have entirely different purposes.
Most other vector "formats" involve plugins (Flash) or hardware support (webGL). Ironically, the VML format you mentioned is now deprecated in favor of SVG.
To answer your question: SVG is now the standard vector format for the web. Hopefully, in the near future, we will see it being used for video/animation as well.
You can try the Raphaël JavaScript Library.
It is easy to implement and provides the same UI features as SVG (and more!).
If it is SVG you are after the best way to go is svg.js. It supports SVG better and it is a fraction of the size (4.5k gzipped) of Raphaël (31k gzipped). It also has a very intuitive syntax.
All major browsers including ie9, firefox, safari and chrome are starting to supporting svg as part of the upcoming html5 standard. I wouldn't call that "dead"
2D: SVG
3D: X3DOM or webGL directly
I woud like to create a cross-platform drawing program. The one requirement for writing my app is that I have pixel level precision over the canvas. For instance, I want to write my own line drawing algorithm rather than rely on someone elses. I do not want any form of anti-aliasing (again, pixel level control is required.) I would like the users interactions on the screen to be quick and responsive (pending my ability to write fast algorithms.)
Ideally, I would like to write this in Python, or perhaps Java as a second choice. The ability to easily make the final app cross-platform is a must. I will submit to different API's on different OS'es if necessary as long as I can write an abstraction layer around them. Any ideas?
addendum: I need the ability to draw on-screen. Drawing out to a file I've got figured out.
I just this week put together some slides and demo code for doing 2d graphics using OpenGL from python using the library pyglet. Here's a representative post: Pyglet week 2, better vertex throughput (or 3D stuff using the same basic ideas)
It is very fast (relatively speaking, for python) I have managed to get around 1,000 independently positioned and oriented objects moving around the screen, each with about 50 vertices.
It is very portable, all the code I have written in this environment works on windows and Linux and mac (and even obscure environments like Pypy) without me ever having to think about it.
Some of these posts are very old, with broken links between them. You should be able to find all the relevant posts using the 'graphics' tag.
The Pyglet library for Python might suit your needs. It lets you use OpenGL, a cross-platform graphics API. You can disable anti-aliasing and capture regions of the screen to a buffer or a file. In addition, you can use its event handling, resource loading, and image manipulation systems. You can probably also tie it into PIL (Python Image Library), and definitely Cairo, a popular cross-platform vector graphics library.
I mention Pyglet instead of pure PyOpenGL because Pyglet handles a lot of ugly OpenGL stuff transparently with no effort on your part.
A friend and I are currently working on a drawing program using Pyglet. There are a few quirks - for example, OpenGL is always double buffered on OS X, so we have to draw everything twice, once for the current frame and again for the other frame, since they are flipped whenever the display refreshes. You can look at our current progress in this subversion repository. (Splatterboard.py in trunk is the file you'll want to run.) If you're not up on using svn, I would be happy to email you a .zip of the latest source. Feel free to steal code if you look into it.
If language choice is open, a Flash file created with Haxe might have a place. Haxe is free, and a full, dynamic programming language. Then there's the related Neko, a virtual machine (like Java's, Ruby's, Parrot...) to run on Mac, Windows and Linux. Being in some ways a new improved form of Flash, naturally it can draw stuff. http://haxe.org/
QT's Canvas an QPainter are very good for this job if you'd like to use C++. and it is cross platform.
There is a python binding for QT but I've never used it.
As for Java, using SWT, pixel level manipulation of a canvas is somewhat difficult and slow so I would not recommend it. On the other hand Swing's Canvas is pretty good and responsive. I've never used the AWT option but you probably don't want to go there.
I would recommend wxPython
It's beautifully cross platform and you can get per pixel control and if you change your mind about that you can use it with libraries such as pyglet or agg.
You can find some useful examples for just what you are trying to do in the docs and demos download.