This question already has answers here:
Rendering Vector Graphics in OpenGL? [duplicate]
(5 answers)
Closed 5 years ago.
I want to use Vector graphics in an OpenGL game. I want to use vector graphics because they can be scaled cheaply without loss of quality.
Of course, the drawing should be hardware accelerated, so I do not want to draw in software to a texture.
Now I am wondering if a library doing this already exists. Is there a library, that can load some vector graphic format and display it using OpenGL?
I would not bother with anything OpenVG, not even with MonkVG, which is probably the most modern, albeit incomplete implementation. The OpenVG committee has folded in 2011 and most if not all implementations are abandonware or at best legacy software.
Since 2011, the state of the art is Mark Kilgard's baby, NV_path_rendering, which is currently only a vendor (Nvidia) extension as you might have guessed already from its name. There are a lot of materials on that:
https://developer.nvidia.com/nv-path-rendering Nvidia hub, but some material on the landing page is not the most up-to-date
http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/opengl/gpupathrender.pdf Siggraph 2012 paper
http://on-demand.gputechconf.com/gtc/2014/presentations/S4810-accelerating-vector-graphics-mobile-web.pdf GTC 2014 presentation
http://www.opengl.org/registry/specs/NV/path_rendering.txt official extension doc
NV_path_rendering is now used by Google's Skia library behind the scenes, when available. (Nvidia contributed the code in late 2013 and 2014.)
And to answer a more specific point raised in the comments, you can mix path rendering with other OpenGL (3D) stuff, as demoed at:
https://www.youtube.com/watch?v=FVYl4o1rgIs
https://www.youtube.com/watch?v=yZBXGLlmg2U
You can of course load SVGs and such https://www.youtube.com/watch?v=bCrohG6PJQE. They also support the PostScript syntax for paths.
An upstart having even less (or downright no) vendor support or academic glitz is NanoVG, which is currently developed and maintained. (https://github.com/memononen/nanovg) Given the number of 2D libraries over OpenGL that have come and gone over time, you're taking a big bet using something not supported by a major vendor, in my humble opinion.
Take a look at OpenVG.
Lots of discussion in this Slashdot post about renderers for SVG. I don't know which of them using OpenGL, if any.
This SO question also has several suggestions, including sauvage which is done in Python. Cairo is also apparently a possibility.
There are several powerful libraries that render SVG without OpenGL. I wonder if it's not really that necessary: maybe drawing lines is already accelerated enough on most systems' graphics cards.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We are a small company with only 2 programmers. We currently make small 2D and 3D games for desktop and mobile using Adobe Flash/Air. We want to stop using that framework and start learning and developing on C++ because there are much more and better libraries and frameworks available on C++.
I'm not sure about the libraries to use for rendering. I know that Ogre3D is a great rendering engine for 3D content but sometimes we need to make 2D games or "2.5D" games, sometimes with video playback, and all that need to be mixed with 3D scenes.
I know there are 2D frameworks like cocos2D-x and smfl that works with OpenGL (I don't know much about OpenGL) and can do all the 2D things I need, but can those frameworks be combined with Ogre3D? And can it be done without the need of knowing how all the Ogre3D internal stuff or OpenGL works?
If Ogre3D can be combined with any 2D engine, what do I need to learn to merge the frameworks?
Given that you have been using flash, I am guessing you are not porting old C++ code.
Also, since you don't want to know about how the internals of the framework you're using or how OpenGL actually works, you don't need a low level language like C++.
An abundance of open source libraries is not a very good reason to program your game in C++ either.
Unity3D has a free basic license, and provides everything you need out of the box.
For now, you can use planes with textures to do your 2D work, but Unity will also be coming out with a set of Native 2D Tools in the near future. Also, a new GUI system is being created.
For any C++ library you think you may need, there is probably something already built into unity that does what you want. If there isn't, there is probably a .NET port that you can use. And if all else fails, you can write a C interface for any library you need, and use it as a plugin in Unity.
One big problem with Unity though, is that you need Unity Pro to use plugins. Unity licenses are per-platform, So if you decide to use plugins, and release your game for multiple platforms, you could end up paying a lot of money in licensing fees.
Finally, it's not just an application framework you'll need. You'll also need a level editor. Building a 3D level editor is not a trivial task, and given that your team consists of only two people, this fact alone should be enough to seriously consider using Unity.
So unless you are porting old code, need low level access to hardware, or have specific needs for native code, my advice is don't use C++, just use Unity.
Yes, Ogre3D can handle such "2D tasks" as playing a video. Simply a plane in 3D space that it gets projected onto. However for pure 2D projects an 3D rendering engine such as Ogre3D is usually overkill. If you are talking about 2,5D though, you are back in play with Ogre3D.
Regarding integrations: Not completely sure, but I guess those other 2D frameworks need an OpenGL rendering context that you can get from Ogre.
EDIT: Same question has been asked in the official Ogre3D forums.
We are another small team working on game development.
We tried many rendering engines and finally settled down with Irrlicht Rendering engine. Irrlicht is no way better than Ogre 3D or am not trying to prove that. We felt Irrlicht more flexible for our need. It also supports 2D rendering and it is quite fast with batching. Irrlicht can be easily ported to other platforms, It took us a week to port it to Google Chrome NaCl.
Irrlicht is a very basic rendering system that supports OpenGL and OpenGL ES, so its easy for your to go mobile. You can add any advanced features without much effort. Some of our games are available for iOS, Android, Windows PC, Mac OSX, Linux and Google Chrome Native Client.
I want to be able to render into an OpenGL render window using DirectX. This is because the features i'm after are only supported in DirectX.
I have heard it is possible to do this a few years ago and i'm hoping it should still be possible.
I'd imagine it will involve pointing DirectX to the correct part of VRAM and the correct depth buffer.
Also a tutorial or simply an explanation would be extremely useful.
At least NVIDIA has the NV_DX_interop extension, which let's you use Direct3D 9 buffers/textures/surfaces directly as OpenGL buffers/textures/renderbuffers (therefore being the other way around). But I don't have any experience with this and I don't know if it is widely supported or actually works any good.
It would be more interresting which features you think are only available in Direct3D. Maybe we can show you how to achieve it with OpenGL, as there are not many features (if any) that are available in Direct3D and not in OpenGL. Although if you got an ATI card, being available and actually working correctly may sometimes be two seperate things.
Mixing OpenGL and Direct3D will not work, and AFAIK it never used to. May I ask, which features of Direct3D you require, that OpenGL doesn't offer?
You can. At least for nVIDIA! Check NV_DX_interop. But however, EVERY DirectX feature is supported in OpenGL as OpenGL is more RAW / Low level than DirectX! Just the way it is implemented may be different. Again, tell us WHICH feature of DirectX you want and I can tell you hints how to reimplement it.
One specific example of a difference between OpenGL and Direct3D, which is something I am researching myself, is that in DirectShow (a subset of Direct3D), there are video capture filters for my Panasonic DVCPRO-HD based cameras. So the live streams collected via that API, I would like to use as inputs into OpenGL libraries. One such library is OpenFrameWorks, which is OpenGL based. I am looking to see how efficient I can make this transfer. The existing OpenFrameWorks Video API uses a slightly older and deprecated DirectShow API, and uses a brute force strategy for getting pixels from DirectShow over to OpenFrameWorks.
This question already has answers here:
Displaying SVG in OpenGL without intermediate raster
(5 answers)
Closed 5 years ago.
Is there a way to load a vector graphics file and then render it using OpenGL? This is a vague question as I don't know much about file formats for vector graphics. I know of SVG, though.
Turning it to raster isn't really helpful as I want to do real time zooming in on the objects.
I see most of the answers are about Qt somehow, even though the original question doesn't mention it. Here's my answer in terms of OpenGL alone (which also benefits greatly from the passage of time, as it could not have been given in 2010):
Since 2011, the state of the art is Mark Kilgard's baby, NV_path_rendering, which is currently only a vendor (Nvidia) extension as you might have guessed already from its name. There are a lot of materials on that:
https://developer.nvidia.com/nv-path-rendering Nvidia hub, but some material on the landing page is not the most up-to-date
http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/opengl/gpupathrender.pdf Siggraph 2012 paper
http://on-demand.gputechconf.com/gtc/2014/presentations/S4810-accelerating-vector-graphics-mobile-web.pdf GTC 2014 presentation
http://www.opengl.org/registry/specs/NV/path_rendering.txt official extension doc
NV_path_rendering is now used by Google's Skia library behind the scenes, when available. (Nvidia contributed the code in late 2013 and 2014.)
You can of course load SVGs and such https://www.youtube.com/watch?v=bCrohG6PJQE. They also support the PostScript syntax for paths. You can also mix path rendering with other OpenGL (3D) stuff, as demoed at:
https://www.youtube.com/watch?v=FVYl4o1rgIs
https://www.youtube.com/watch?v=yZBXGLlmg2U
An upstart having even less (or downright no) vendor support or academic glitz is NanoVG, which is currently developed and maintained. (https://github.com/memononen/nanovg) Given the number of 2D libraries over OpenGL that have come and gone over time, you're taking a big bet using something not supported by a major vendor, in my humble opinion.
This isn't an implementation, but very relevant to your question and viewers.
Chapter 25. Rendering Vector Art on the GPU
https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch25.html
Let me expand on Greg's answer.
It's true that Qt has a SVG renderer class, QSvgRenderer. Also, any drawing that you do in Qt can be done on any "QPaintDevice", where we're interested in the following "paint devices":
A Qt widget;
In particular, a GL-based Qt widget (QGLWidget);
A Qt image
So, if you decide to use Qt, your options are:
Stop using your current method of setting up the window (and GL context), and start using QGLWidget for all your rendering, including the SVG rendering. This might be a pretty small change, depending on your needs. QGLWidget isn't particularly limiting in its capabilities.
Use QSvgRenderer to render to a QImage, then put the data from that QImage into a GL texture (as you normally would), and render it any way you want (e.g. into a rectangular GL_QUAD). Might have worse performance than the other method but requires the least change to your code.
Wondering what QGLWidget does exactly? Well, when you issue Qt rendering commands to a QGLWidget, they're translated to GL calls for you. And this also happens when the rendering commands are issued by the SVG renderer. So in the end, your SVG is going to end up being rendered via a bunch of GL primitives (lines, polygons, etc).
This has a disadvantage. Different videocards implement OpenGL slightly differently, and Qt does not (and can not) account for all those differences. So, for example, if your user has a cheap on-board Intel videocard, then his videocard doesn't support OpenGL antialiasing, and this means your SVG will also look aliased (jaggy), if you render it directly to a QGLWidget. Going through a QImage avoids such problems.
You can use the QImage method when you're zooming in realtime, too. It just depends on how fast you need it to be. You may need careful optimizations such as reusing the same QImage, and enabling clipping for your QPainter.
Qt has good support for directly rendering SVG images using OpenGL functionality (see the documentation for QSvgRenderer).
I hope that helps.
It has primitives like GL_LINES and GL_LINE_STRIP for drawing lines in space if that's what you mean. Edit: This site has some information: http://www.falloutsoftware.com/tutorials/gl/gl2p5.htm
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
Trying to decide on a library for creating a window and capturing user input for my OpenGL app, but there are just way too many choices:
GLUT (win32)
FreeGLUT
OpenGLUT
SFML
GLFW
SDL
FLTK
OGLWFW
Clutter
Qt
Others?
GLUT is simply outdated. I liked GLFW but it seems you can't set the window position before displaying it (I wanted it centered, is that so much to ask?) so you see it appear and then shift over, which bothers me. Plus development seems to have stopped on it too. SFML has some nice features, but it uses event polling rather than callbacks which I prefer for decoupling. I don't think I need all the GUI features of FLTK. SDL is slow (doesn't seem to take advantage of the GPU). And the other 3 I don't know much about (FreeGLUT, OpenGLUT, OGLWFW). So which is the lesser of the evils? Are there others I haven't heard about?
I'm just trying to make a simple 2D game. I'm familiar enough with OpenGL that I don't really need drawing routines, but I probably wouldn't complain about other functions that might be useful if they are implemented properly.
SDL allows you to create an OpenGL context that is accelerated (depending on drivers / hardware support).
I know you tagged as C++, however pygame (python) is a great library for creating 2D games, which also supports an OpenGL context. Pygame is built on SDL.
Clutter is a new OpenGL based GUI library with bindings for Perl, Python, C#, C++, Vala and Ruby. I haven't used it myself. From the website:
Clutter uses OpenGL (and optionally
OpenGL ES for use on Mobile and
embedded platforms) for rendering but
with an API which hides the underlying
GL complexity from the developer. The
Clutter API is intended to be easy to
use, efficient and flexible.
GLUT and the other GLUT alternatives should not be used in any sort of production application. They are good for putting together a quick demo application or to try something out, but not for much more than that.
If you're trying to make an OpenGL game, I'd recommend SDL. It focuses more on gaming needs. It most definitely can be used with OpenGL. A brief google for "SDL OpenGL" turned up this link on how to initialize OpenGL with SDL. Enabling OpenGL should also enable hardware rendering with the GPU.
Qt is a reasonable alternative, but it's better if you want to embed OpenGL within a larger, desktop application (think 3D modeling, CAD/CAM, medical visualization, etc) where you need access to standard OS widgets for the UI.
I'd go for Qt. Nice general purpose library + opengl support
IF "learning c++ part of what you're trying to achieve":
then
IF "you only want to learn OpenGL with a fullscreen mode":
USE GLUT //Because it's VERY VERY simple. You can get set up VERY quick
ELSE:
USE QT //Great library, has many many things that will help you. It is portable, it has a nice API
ENDIF
IF "you don't need C++":
then
USE Python //I recommend it, it is fast, no long link times, good api, omg I love this language
Background:
I also tried to make simple 2D games once, I started with C++ and NeHe. I knew nothing about OpenGL and C++ (had Java background). The language overrun me, so did OpenGL. So it was a very hard learning curve.
I don't recommend going that way, since you can get faster results by using a dynamic language (such as Python). So I started learning some years later with python. I could get the "rotating cubes" working much faster.
We have had rather good experiences with ClanLib 0.8 in 2008 and ClanLib 2.1 in 2009 on our C++ course. The productivity of the students (as measured by the quality of their project works) has greatly increased since switching over from SDL. However, it needs to be noted that 2.1 is still very incomplete and one will certainly run into features that are simply not implemented yet.
A couple of groups used Irrlicht (3D engine) with good results.
SFML looks promising, but I haven't had a chance to try it yet.
As others have stated, GLUT is not really suitable for anything serious. The rest of the libraries mentioned are something more of GUI toolkits than game development libraries.
Per recent corespondance with the author, development on OGLWFW has stopped.
I am looking for a cross-platform solution for saving and viewing 3D scenes (visualizations of engineering simulation models and results) but there (still) doesn't seem to be much out there.
I looked into this almost 10 years ago and settled on VRML then (and started the project that eventually turned in OpenVRML). Unfortunately, VRML/X3D has not become anywhere near ubiquitous in the past decade.
Ideally a solution would offer a C++ library that could be plugged in to a 3D rendering pipeline at some level to capture the 3D scene to a file; and a freely redistributable viewer that allowed view manipulation, part hiding, annotation, dimensioning, etc. At least linux, mac, and windows should be supported.
3D PDFs would seem to meet most of the viewer requirements, but the Adobe sdk is apparently only available on Windows.
Any suggestions ?
The closest thing that I'm aware of is Collada.
Many 3D engines can read it, and most 3D design tools can read and write it.
I believe the Ogre engine has pretty good support.
If you are using OpenGL, GLIntercept will save all OpenGL calls (with the data they were called with) to a XML file. It's only half the solution, though, but it shouldn't be hard to parse it and recreate the scene yourself.
Take a look at Ogre3d.org. Its just an engine, you must program with it. But OGRE is probably the better (free/open) platform to develop 3D right now.