As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know there are some question about learning OpenGL.
Here is what I know:
math for 3D
3D theory
Here is what I want to know:
- OpenGL 4.0 Core profile (or latter)
- Shader Language 400 (or latter)
- every part of above (if it do not work across vendors then it still do not bother me)
Here is what I DO NOT want to know
- fixed function pipeline (will not use it ever!)
- older OpenGL's
- Compatibility profile
I prefer bigger portion of info like tutorials, series of articles, books.
PS If you know resources on opengl 3.x core profile, post them too
I cordially dislike negative answers, but I'm afraid I have to give one to this question.
You are ultimately asking for beginner material that uses features unique to OpenGL version 4.0 and above. Well, let's look at some of the unique features of 4.x.
Perhaps the biggest feature is tessellation. What does that mean? It means tessellating primitives to generate more primitives. Before one can even begin to understand what that means, one must first understand how primitives get rendered at all. That uses pre-4.x level features.
But even with a firm understanding of how rendering works, there is still a problem. In order to have any meaningful discussion of tessellation shaders, one must first have a strong understanding of tessellation algorithms. And that is not a simple subject. For a tutorial to teach a user to use tessellation shaders, the tutorial will first have to introduce spline curves and patches or subdivision surfaces. Both of these are lengthy topics that have numerous white papers devoted to them. Only after detailing the algorithms would a user be ready to see how those algorithms are implemented in the tessellation shader.
Or, to put it another way, tessellation shaders are not beginner material. I wouldn't even qualify them as intermediate-level material.
Another big feature of 4.x level hardware is shader image load store (and its companion, atomic counters), core in 4.2. It allows for some very nifty things, including order-independent transparency. However, in order for a user to even begin to understand all of the quirks around it, the user needs to be intimately familiar with the deep workings of modern shader hardware. So any tutorial would first have to explain how modern VLIW/SIMD-based hardware works, as well as how shaders are used with such hardware. Again, this is not trivial material.
Another big feature of 4.x hardware is indirect rendering. That is, putting the parameters to a glDraw call in the buffer object itself. The problem is that there is really only one reason to use this functionality: because the GPU generated data directly into one or more buffers for later rendering. And doing that usually involves some form of GPGPU operation, which is very much not a beginner-level topic.
All of these features are useful and have a real purpose. But none of them should be used by beginners; in some cases, not even intermediate-level programmers should touch them.
Now to be completely fair, there are some 4.2 features that are both non-hardware-based (so they are often implemented on 3.3 and lower versions) and quite useful. Separate program objects, for example. These features hit while I was writing my 3.3-based tutorials, and I considered going back over them and incorporating this functionality. The only reason I didn't is because implementations (drivers) are still not entirely stable with regard to this functionality. But it would be useful to do.
The main point I'm getting across is this: if you are at the stage in your graphics knowledge where you are ready to take advantage of the unique features of GL 4.x hardware, then you also have enough graphics experience that you don't need an explicit step-by-step instructional material to implement features of graphics hardware. You would be the kind of person who could read the GL_ARB_tessellation_shader extension specification and understand how to make them do what you need to.
That being said, if you are interested in material that teaches OpenGL core 3.0 or better, the OpenGL Wiki has a nice collection of such links. In the interest of full disclosure, I did write one of them.
The 5th edition of OpenGL SuperBible has been recently released. This edition reflects OpenGL 3.3 which was released at the same time as OpenGL 4.0, the book only covers the core profile and assumes no prior OpenGL knowledge.
That's what I got from the book's description anyway. I have the 4th edition and it's an excellent resource for OpenGL 2.0, so I assume the new edition along with the latest OpenGL Shading Language book would be just what you're looking for.
Durian Software has an ongoing series of tutorials covering modern OpenGL. They are aimed at OpenGL 2.0 but avoid using any deprecated functionality in later versions.
There is really very little difference between OpenGL 3.0 and 4.1. If you stick to 3.0 or later core profile, you can't use the fixed function pipeline. What you're really asking for is an OpenGL tutorial that does not use the fixed function pipeline.
Jason L. McKesson's excellent tutorial "Learning Modern 3D Graphics Programming" starts out using shaders for the very earliest basics, and never touches the fixed function pipeline.
http://www.arcsynthesis.org/gltut/index.html
I highly recommend it.
I recently stumbled on this online book:
OpenGLBook.com
I haven't read it yet, but description says that it is a free OpenGL 4.0 programming resource in online book format.
Excellent question, really. As a matter of fact, documentation is sparse.
There is a good introduction here : http://sites.google.com/site/opengltutorialsbyaks/
You may also like groovounet's ogl4 samples pack : http://www.g-truc.net/post-0310.html
but I'm afraid that's pretty much it. Lurk on the opengl discussion boards for more info ...
EDIT : found a few seconds ago. Straight from SIGGRAPH http://nvidia.fullviewmedia.com/siggraph2010/02-dev-barthold-lichtenbelt-mark-kilgard.html
http://www.opengl.org/sdk/docs/man4/
There's the man pages for OpenGL 4.1, they prove to be useful when developing.
I think one of the best hopes you have is Joe's Blog. It has a few good introductory articles on modern OpenGL, with more (supposedly) on the way.
Swiftless is updating tutorials to include new context. A good starting tutorial that has been more straight-forward regarding a quick and simple VAO, VBO and render is located at swiftless.com
Have not read it, but OpenGL 4.0 Shading Language Cookbook
The major point of OpenGL 4 is tesselation so i would like to recommend to start from a standalone tutorial on OpenGL 4 tesselation, i.e: http://prideout.net/blog/?p=48
After manuals and tutorials a good follow-up is to take a look at the open-source engines out there that are based on top of "new" OpenGL 3/4. As one of the developers, I would point at Linderdaum Engine.
free resource:
http://www.arcsynthesis.org/gltut/index.html
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I just watched a very impressive presentation from Siggraph 2012:
http://nvidia.fullviewmedia.com/siggraph2012/ondemand/SS106.html
My question is, this being a proprietary Nvidia extension, what are the other possibilities to quickly renderer Bezier paths on GPU? Alternatively, is there any hope this will end-up as part of OpenGL standard? Is it possible to give any time estimate on when this eventually happens?
Do you know of any other (preferably open source) project dealing with GPU path rendering?
Edit: There is now a new "annex" to the original paper:
https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/nvpr_annex.pdf
Ready made alternatives
NanoVG (https://github.com/memononen/nanovg) appears to have a little bit of traction (http://www.reddit.com/r/opengl/comments/28z6rf/whats_a_popular_vector_c_library_for_opengl/). So you could look at their implementation. I have not used NanoVG myself though and I'm mostly unfamiliar to its internals; what I do know is that they have specifically rejected using NV_path_rendering: https://github.com/memononen/nanovg/issues/25
As I mentioned already in a comment above, NV_path_rendering has now been implemented in Skia and appears to be courted by cairo too, see my comment below tjklemz's answer above for links on those details. One issue with NV_path_rendering is that it is somewhat dependent on the fixed-function pipeline, so a bit incompatible with OpenGL ES 2.0., but there's a workaround for that https://code.google.com/p/chromium/issues/detail?id=344330
I would stay away from anything OpenVG-related. The committee working on that has folded in 2011; it's now basically a legacy product/API. Most implementations of OpenVG (including ShivaVG) are also ancient and use fixed-function OpenGL according to https://github.com/memononen/nanovg/issues/113 If you really must use an OpenVG-like library, MonkVG appears the most well maintained [read as: the most recently abandoned] among the free ones (code: https://github.com/micahpearlman/MonkVG; 2010 announcement http://www.khronos.org/message_boards/showthread.php/6776-MonkVG-an-OpenSource-implementation-available). They claim it works on Windows, MacOS X, iOS and Android via OpenGL ES 1.1 and 2.0. The [fairly big] caveat is that MonkVG is not a full implementation of OpenVG; see the "TODO" section on their code page for what's missing.
I also found that a cairo (& pango) dev, Behdad Esfahbod, has written a new glyph (i.e. font) rendering library (https://code.google.com/p/glyphy/): "GLyphy is a signed-distance-field (SDF) text renderer using OpenGL ES2 shading language. [...] GLyphy [...] represents the SDF using actual vectors submitted to the GPU. This results in very high quality rendering." As far as I can tell it's not used in Cairo yet. (Behdad moved to Google [from Red Hat] and cairo hasn't seen releases in quite a while, so maybe GLyphy is gonna go into Skia instead, who knows...) I'm not sure how generalizable that solution is to arbitrary paths. (In the other direction, NV_path_rendering can also render fonts and with kerning, in case you didn't know that.) There is a talk at Linux.conf.au 2014 which you should definitely watch if you're interested in GLyphy: https://www.youtube.com/watch?v=KdNxR5V7prk If you're not familiar with the (original) SDF method, see http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
I found a talk by a Mozilla dev which summarizes the common approaches in use today: https://www.youtube.com/watch?v=LZis03DXWjE#t=828 (The timestamp is to skip the intro part where he tells you what a GPU is.)
DYI (possibly)
By the way, a lot of the path-rendering stuff is command/state-change-intensive. I think that Mantle, DX12, and the OpenGL equivalents of that (mostly extensions http://gdcvault.com/play/1020791/) will probably improve that a fair bit.
I guess I should also mention that Nvidia has been granted (at least) four patents in connection with NV_path_rendering:
https://www.google.com/patents/US8698837
https://www.google.com/patents/US8698808
https://www.google.com/patents/US8704830
https://www.google.com/patents/US8730253
Note that there are something like 17 more USPTO docummets connected to these as "also published as", most of which are patent applications, so it's entirely possible more patents may be granted from those. Update on this: Google doesn't quite link all of them together, so there are some more that have been granted for sure:
https://www.google.com/patents/US8786606
https://www.google.com/patents/US8773439
I'm not sure under what terms they are willing to license those...
I found a really nice FAQ by Kilgard himself for "what's special about vector-graphics/path-rendering" which is unfortunately buried somewhere in the OpenGL forum http://www.opengl.org/discussion_boards/showthread.php/175260-GPU-accelerated-path-rendering?p=1225200&viewfull=1#post1225200. This is quite a useful reading for anyone considering quick/hack alternative solutions.
There is also one new thing in Direct3D 11.1 that's possibly useful because Microsoft used it to improve their Direct2D implementation with it in Windows 8; it's called target independent rasterization (TIR). I don't know much about it other than that Microsoft has a patent application on it. http://www.google.com/patents/US20120086715 The catch is that only AMD GPUs seem to actually support it per this "war of words" http://www.hardwarecanucks.com/news/war-of-words-between-nvidia-and-amd-over-directx-11-1-support-continues/
Adoption
I don't have a crystal ball as to when NVpr is going to get adopted by non-Nvidia, but I think they are pushing it quite hard. The OpenGL 4.5 Nvidia presentation has pretty much been taken over by that--at least as far as demos ware concerned, which I thought was a bit silly (since it's not part of OpenGL 4.5 core). Neil Trevett also covered NVpr more than once (e.g. https://www.youtube.com/watch?v=eTdLwfOLoG0#t=2095) and Adobe Illustrator beta 2014 is using it as well as Google's Skia.
ShivaVG is an open source alternative for path rendering. See this Stack Overflow question for a list of OpenVG implementations: Best OpenVG Implemenatation
Basically, you have a few options: use an OpenVG implementation (like ShivaVG), use an OpenGL implementation or extension (like the NV_path_rendering), or use something else entirely, like Direct2D.
However, other alternatives to NV_path_rendering cannot even come close to its feature set and the quality of its render. NV_path_rendering can natively handle fonts (which is a big deal—without fonts, you're toast), scale and so forth in true perspective (try that in Illustrator!), mix well with 3D, use sRGB, use fragment shaders, and does all this incredibly fast. It also implements user-interaction, which OpenVG does not specify AFAIK.
Uniquely, NV_path_rendering does not invent a new standard. Rather, it implements several industry standards, such as PostScript and SVG, with a focus on quality and speed (it's rare to have them both) that you cannot currently find anywhere else.
(Plus, Mark Kilgard is the project lead. C'mon. The guy's brilliant.)
Will it become standard? Hard to know. As for what to use, it really depends on your purpose/need at this point. Looking for quality path rendering for an app? NV_path_rendering for sure. Looking for basic resolution independent graphics in apps (esp. mobile)? OpenVG might be better. It's too bad that Nvidia's solution is not completely portable, but I wouldn't shy from using it. I'd prefer having a quality solution; sometimes portability isn't everything.
Nvidia has compared their solution to OpenVG and found that OpenVG doesn't provide too much benefit, unfortunately. So, yes, there might be hope for it to become a standard. But, since according to IBM everything in the future will be embedded, perhaps it would be better to hope for it to be open, instead of wanting more standards.
"The nice thing about standards is that you have so many to choose from." --
Computer Networks, 2nd ed., p. 254
For more info on NV_path_rendering features, I recommend looking at this: An Introduction to NV_path_rendering.
what are the other possibilities to quickly renderer Bezier paths on GPU?
In-Situ tesselation of a set of control points into convex patches defines by a triangular hull using a tesselation and/or geometry shader. Then passing the curvature parameters to a fragment shader that performs a per-fragment test if the fragment is within the boundaries of each patch and discarding it otherwise.
If an approximation is in order then just tesselating into a triangular mesh is in order.
What are some good resources for learning OpenGL 4.1 aimed at someone relatively new to graphics programming?
I'm aware that this was asked before, but I would think that ~9 months would give us more.
I know that OpenGL Programming Guide: The Official Guide to Learning OpenGL, Versions 4.1 (8th Edition) is coming out apparently in October, but is there anything else? It seems like there's been some major changes, and I'd hate to feel like my time studying until this book release was wasted. Sites can work too, provided they are focusing on 4.1.
Thank you.
If you want to learn graphics programming properly then OGL 4.1 is the place to start these days, but if as a beginner you want to hack stuff out then i'd advise you take an easier route (DirectX). Your programming skills have to up there and especially your maths skills aswell (linear algebra). Get a copy of the Spec and the Red/Orange and Blue books, a good book on mathematics for 3d graphics and prepare for alot of pain, pure 4.1 from scratch is hard.
Don't worry about not getting the latest edition of the red book, 3.3->4.1 didn't change a huge amount in terms of new features or paradigm, mainly just removing deprecated functionality.
Mesh loaders can be fulfilled by OpenCTM, GXBase is also quite good.
Don't bother learning OGL prior to 4.1, it's based on a deprecated paradigm and so you will waste time learning stuff that is officially out of date. The super bible has a good amount of code that will help you along the way.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I just purchased the fifth edition of the OpenGL SuperBible. I'm very pleased that they've avoided using deprecated functionality but their examples make use of GLTools. GLTools provides a slew of useful functions for rendering simple 3D objects and managing the view frustrum, camera, and transformation matrices.
This is all great but the abstraction provided hides low-level details and I'm having difficulty moving to code where I can't use GLTools -- for example, pyopengl. The vast majority of tutorials I've seen online make use of immediate mode, which I'm trying to avoid. Those that use glDrawArrays make use of glEnableClientState, which I'm also trying to avoid.
What I'm looking for is introductory tutorials that are fully OpenGL 3.x compliant. If that's too tall of an order, perhaps a laundry list good "starting point" functions would be in order.
Stay away from NeHe, the tutorials are hopelessly outdated and contain a lot of "problematic" stuff, too.
For starting with 3.x, try those, they're both up-to-date:
Aurian (Joe Groff)
Arcsynthesis (Jason L. McKesson)
Update:
Re-reading my own post almost 2 years later, I guess that one might find that it sounds a bit harsh.
This is of course not the intent. The core message (which remains valid) that I wanted to give was that NeHe still deals with OpenGL 1.x/2.x and uses some unsupported "antique" libraries.
Generally, as such, this does not mean the tutorials are necessarily bad, but starting from there will mean starting two generations behind the current state-of-the-art, and one generation behind the minimum one should learn. Learning legacy OpenGL will, at a later time, require you to forget almost everything you know and re-learn from scratch.
That said, the NeHe front page now links to a tutorial focussed on OpenGL 3.3 by Damien Mabin, which looks quite nice at first sight (though I will not have time to thoroughly read through it before new year).
https://bitbucket.org/rndblnch/opengl-programmable
a short step by step tutorial to OpenGL programmable pipeline (OpenGL / OpenGL|ES 2.x) for people already familiar with the fixed pipeline. dependencies: python 2.5+, PyOpenGL 3.0.1+
Successive versions of a small but rather complete glut/opengl program that starts from direct mode and is transformed step by step to run exclusively on the programmable pipeline.
Look at the diffs between successive version to have an highlight of the changes needed (e.g., https://bitbucket.org/rndblnch/opengl-programmable/changeset/b21131e37ed7).
Here is a serie of OpenGL 3.3 tutorials for Windows, that doesn't use any of deprecated functionality, only new stuff:
Megabyte Softworks OpenGL 3.3 Tutorials
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
OpenGL or DirectX?
Not want to trigger war, but really want to know pros and cons of those two mainstream graphic library?
To be honest the hard part is not the API, it's the higher level 3d stuff. Below that both APIs have vertex buffers, index bufers, textures, shaders, and so on and although they express that in different ways it's the concepts that are the hard part not the API. If you understand d3d11 then you'll pick up opengl in no time and vice-versa.
Practical considerations are that opengl is available on more platforms, but that d3d tends to be better supported and work better on windows platforms. d3d has a more object oriented interface whereas opengl has a strictly "c" style interface (Although it deals internally with objects through "names" and handles). This likely makes opengl easier to start learning than d3d11 which needs quite a bit of setup - but in "real" applications there won't be much in it.
d3d11 is designed to work better on multi core cpus and mult threaded software. This adds some complexity to using it, but allows you to perhaps take more advantage of the hardware then opengl might at this point in time. (However if you are still at the stage of asking which to use then it's very unlikely to matter to you!)
it tends to be much easier to find documentation for d3d9 than opengl (I mean for "modern" stuff, not examples using obsolete ways of doing things, (which is a problem with opengl, a lot of the tutorials and code out there is frankly obsolete and doesn't really use opengl properly now). Whereas it's quite hard to find good d3d11 examples and tutorials still.
If you've not used either I would very much recommend learning the basics of BOTH and the slightly different approaches to the same underlying functionallity. Don't get caught up in saying one is better than the other, learn both and see which seems a better fit. This is what most people do, unfortunatly most of the "advice" you'll get on the internet seems be to from someone who has decided that pushing one or the other API is important to them!
I found it a useful excercise when learning to abstract out the differences with a small c++ framework that creates textures, vertex buffers, index buffers, renderstate collections etc, and implements those concepts in terms of BOTH apis/.
OpenGL is a cross-platform API for 3D graphics. DirectX is a restricted-platform API for graphics, audio, music, device input, networking, and more.
Fist of all, DirectX is a lot more than 3D accelerated rendering. I assume you are talking about Direct3D.
Anyway, here's my completely biased opinion:
Direct3D runs on Windows, Xbox, and sometimes Wine (depending on the particular application/game). Choosing Direct3D ties your product heavily to Microsoft platforms.
Coding in Direct3D (at least the last time I tried it, which was some years ago) makes rolling around naked in honey, walking up to a hornet's nest, and beating the tar out of it sound like a pleasant afternoon.
OpenGL runs on almost every platform imaginable and supports most of the same stuff that Direct3D does in immediate mode.
The OpenGL API is mostly clean and a joy to code against.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is there a good book that focuses on the programmable aspect of OpenGL 3.0
I want something like the OpenGL Super Bible, but focusing solely on the "new testament" part -- the programmable rather than the fixed pipeline.
The Orange Book: http://books.google.it/books?id=kDXOXv_GeswC&dq=opengl+shading+language&printsec=frontcover&source=bn&hl=it&ei=KChiS7-_Ityi_QarxsyMDA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CB4Q6AEwAw#v=onepage&q=&f=false
The latest 5th edition of the OpenGL SuperBible does focus only on the core profile. Unfortunately it includes it's own gltools library so most of the start of the book is really more teaching that toolkit rather than the core profile itself, of course it covers the basic overall layout of a modern opengl program and does seem to fill in the harder stuff later. As you progress though it seems you reimplement the crutch library.
The OpenGL Programming Guide (The Red Book) 7th edition, unfortunately seems to be rather dated. They have marked everything that is in the compatibility profile rather than the core, but thats about it.
There is an 8th edition being released in December 2012 that is apparently a rewrite teaching modern approaches.
Realistically it would be best to learn the specific areas on the compatibility profile/OpenGL 2.1 then combine them all together into something that is core profile. Doing it all at once is just too much at once.
First learn Vertex Buffer Objects (and ditch glBegin/glEnd and anything that goes in between).
Learn manual Matrix operations and stack, or an appropriate library (ditch glPushMatrix/glTranslate/glRotate/glOrthagonal/gluLookAt/glFrustum, you may need to use some compatibility stuff to bind your manually processed marices at this stage but you can ditch them with the shader next step)
Learn Vertex & Fragment shaders
Learn how to set the OpenGL context to 3.1+ (Dependant on your windowing system).
The book OpenGL Programming Guide: The Official Guide to Learning OpenGL, Versions 3.0 and 3.1 (7th Edition) was updated and explains the new features of OpenGL 3.0.
If you want a shorter, simpler OpenGL book that covers just the programmable pipeline, I'm going out on limb and recommending OpenGL ES 2.0 Programming Guide. OpenGL ES 2 is a subset of OpenGL, to make it simpler for embedded systems. For most situations where there is more than one way of doing something in OpenGL, the OpenGL ES standard includes only one way. Version 2 of OpenGL ES is for programmable hardware, and therefore includes just the programmable pipeline stuff. Since OpenGL ES is a subset of OpenGL, everything in OpenGL ES will work on an OpenGL implementation. Whereas the "OpenGL Programming Guide" is 936 pages long, the "OpenGL ES 2.0 Programming Guide" is merely 480 pages long.
"The Red Book" was the openGl book when i was studying it, but that was long ago, you'd have to find out if they've continued to update it as far as v3.