So there has been a lot of times where I needed to know what the enums returned by certain opengl operations are, to print them on the terminal to see what's going on.
It doesn't seem there's any kind of function available for stringifying the enums at the moment, so I'm thinking of going straight to gl.h (actually I'm gonna use libglew's header for now), grabbing the #defines and creating a huge switch table for convenience purposes.
Is there any better way, and how would you deal with having to port things to OpenGL ES?
gluErrorString is the function you're looking for in OpenGL, as GLU library is normally always available alongside with GL.
I don't have experience in OpenGL ES, but Google turned up GLUes that may help you.
OpenGL has some official .spec files that define the API, there is one enum.spec that lists all the enum names and their values. You just need to write a simple program to parse the file and produce a lookup mapping.
The file can be found at http://www.opengl.org/registry/ (specifically http://www.opengl.org/registry/api/enum.spec)
Manually processing gl.h would work but the spec files are updated for new versions and if you have a program to generate the code for you then you don't have to do anything to get the new enums in. Also gl.h file is implementation specific. So it might change between nVidia, ATI, and on different platforms.
The OpenGL Registry contains comprehensive information on the OpenGL API. Notably the gl.xml file in the XML API registry lists all enums, including their names and values. Creating a lookup table from that data should be simple enough.
Related
I'm trying to debug some OpenGL 3.3+ graphics code using RenderDoc and I would like to define some debug markers for render passes that can be recognised by RenderDoc.
I use GLEW and I tried to use glPushGroupMarkerEXT/glPopGroupMarkerEXT to define these markers but I get an access violation when I call glPushGroupMarkerEXT, so I guess that the extension that provides that functionality is not loaded.
I also tried to check if the extension GL_EXT_debug_marker is available using glewIsSupported but that returns false.
Is this functionality not supported or am I not using it properly? Or is there any other way of achieving this?
EXT_debug_marker is not the extension you want to use. It is old and was never really widely supported. Its functionality was absorbed into KHR_debug, which is more widely supported and itself has been core OpenGL since 4.3 (aka: 5+ years ago).
Now, debug marker functionality is different between the two. KHR_debug makes markers into just another kind of user-defined debug notification. So, where you would have called glInsertEventMarkerEXT, you instead call the more generic glDebugMessageInsert, using the GL_DEBUG_TYPE_MARKER as the message's type. Where you would use glPush/PopGroupMarkerEXT, you instead use glPush/PopDebugGroup, which is used for arbitrary scoping. Such groupings don't use the marker type; they use the GL_DEBUG_TYPE_PUSH/POP_GROUP types, so that you can tell the difference between grouping and markers.
Is there a library/tool that can be used in C/C++ that would convert the PS (post script) file to .PDF file, on embedded platform (proprietary operating system, no windows, no linux)?
I was looking for some kind of library that could be ported to our OS. I have found basically only Ghostscript, but issue there is with the license, if i understood it correctly, we would have to make our source public, which is not possible for us...
Maybe a little bit more background, we are trying to find format that will be easily viewable by user. We already have our output in PS for other reasons (printer). But now we want to provide this output in file by itself, so we are trying to find feasible file format. We are considering the PS itself, but usual user does not have PS viewer, so that's why I am trying to find something to convert this to PDF. So perhaps alternative question could be, is there some another format that can be easily acquired from PS, such that "regular" user can view it?
The main complexity for converting PostScript to something else comes from the fact, that PostScript is a programming language and PostScrip files in fact are programs executed on the printer.
In contrast to PostScript, PDF is not a programming language. When converting PostScript to PDF (or anything else), you actually have to run the PostScript program and record the graphic primitive calls, executed during the execution of the PostScript program.
This general approach is needed, when you want to convert PostScript programs from any source to PDF.
But you wrote, that you are creating the PostScript code yourself. Perhaps your PostScript program is just a linear sequence of calls to drawing primitives and does not use anything like subroutines or control structures.
If not, it might be easy to change your generator to do those computation at creation time,that currently are performed at print time. You would end up in a linear sequence of calls to drawing primitives.
When there are no more computations done at print-time, it should not be too hard to directly create PDF instead of PostScript. This answer mentions an open source PDF generation library, that uses an MIT style license.
The AGPL licence for Ghostscript would require you to make your source open, yes. However Ghostscript is dual licenced, in addition to the AGPL licence you can purchase a commercial licence, which doesn't require you to open source your own code.
Rather than converting to PDF you can, of course, also simply use Ghostscript to render the PostScript to a bitmap, its usually pretty easy to wrap a viewer around that.
I should point out that there are other companies offering commercial licences for PostScript interpreters which are capable of creating PDF files and/or rendering PostScript. Adobe is the obvious one, there's also Global Graphics.
These days there are not many players left in the field, if you want to handle PostScript, and the AGPL or similar licences won't suit you, then you will need to go commercial.
What is the best way/common practice for maintaining all string resources found on a UI in Qt, especially the textual input/text in combo boxes etc. (since these are the once that are frequently used in the code itself)?
I know that Android has this string resources thing such that resources only have to be modified at one position.
Does Qt have something like that too or do I have to initialize string resources in code instead of in the UI's XML itself...
AFAIK, there is no built-in mechanism for string resources in Qt. If you want to maintain strings at build time you can define them in one .h/.cpp file as global variables and reuse them in your code.
Otherwise you can use Qt's translator files (binary) and load them along with your application. If you need to change a string, you simply will need to edit the translation file (xml) and "recompile" it with lrelease utility without building the application again.
There is a mechanism to dynamically translate texts in application, but it works a bit different than Android string resources, but achieves the same goals.
Qt uses i18n system modelled after standard, well known unix gettext. It works in a very similar way to iOS NSLocalizedString, if that rings a bell.
http://doc.qt.io/qt-5/qobject.html#tr
This is worth reading too:
http://en.wikipedia.org/wiki/Gettext
http://doc.qt.io/qt-5/internationalization.html
Android approach is a bit unique and you should not expect it to be a "standard everywhere". It works, it's ok, but it's not a standard way of doing things on desktop.
If you wanted to:
model an object in a 3D editor, e.g. Blender, Maya, etc
export the model into a data/file format
import the model into an project using OpenGL and C/C++
Then:
What file format would you recommend exporting to, i.e. in terms of simplicity, portability, and compatibility (i.e. common/popular)?
What graphics libraries would you recommend using to import the model into your OpenGL C/C++ project (i.e. preferably open source)?
Additionally, are there data/file formats that also capture animation, i.e. an "animated model" format, such that the animation could be modeled in the 3D editor and somehow invoked inside the code (e.g. accessibility to frames in the animation sequence or some other paradigm for saving/loading details related to changes over time)?
Generally speaking, I'm seeking simplicity as the priority, i.e. help to get started with combining my backgrounds in both art and computer science. I am a computer science major at UMass while at the same time, sort of a "pseudo" double-major in art by taking electives in graphic design at my university as well as classes at the Art Institute of Boston during summer/winter sessions So, in other words, I am not a complete newbie, but at the same time I don't really want options that are so overloaded with crazy advanced configurations making it too difficult to get started with a basic demonstration project; i.e. as a first step to understanding how to bridge the gap between these two worlds, e.g. creating a program featuring a 3D character that the user can interact with.
COLLADA (I'm saying it with a "ah" at the end), and Assimp (ple as that).
And so, why COLLADA? Simple:
COLLADA is an open standard made by Khronos (Sony specifically). The beauty of an open standard format is that it's, well, a standard! You can be assured that any output of a standard-conformant product would also read correctly by another standard-conformant product. Sad to say though, some 3d modelling products aren't that particular in their measures for standards conformance for COLLADA. But still be rest assured: Blender, Maya, 3ds Max and all the other big names in 3d modelling has good support for the format.
COLLADA uses XML. This makes it much more simpler for you if your planning to create your own reader or writer.
ADDITIONAL: COLLADA is, I think, the only format that is not tied to a specific company. This is a very good thing for us, you know.
ADDITIONAL 2: It is known that COLLADA is slow to be parsed. That's true. But think of it: all other non-binary formats (like fbx) have also the same issues. For your needs, COLLADA should suffice.
ADDITIONAL 3: COLLADA supports animations!
For the importer library, I highly recommend Assimp. Why?
Assimp has support for any popular format you can imagine. It has a unified interface for all formats so that switching to another format is less of a pain.
Assimp is extensible. You can thus import your proprietary format and still not modify your code.
ADDITIONAL 4: Assimp is open source! Let's support open source software!
First , here you can read about suggested model loading lbs.Lib Assimp is really good and supports many formats.For the preferred formats.Collada-I wouldn't recommend because that is XML (text) based formats which is slow to parse. Obj format is also widespread but suffers from the same problems as Collada.It is still good if you want to write your own parser as its structure is very simple.But Instead I would suggest 3Ds which is binary.It doesn't support animations though.The most popular format today which supports both static mesh and animation is FBX.You can download for free FBX SDK from Autodesk and connect it to your engine.The reason I would choose FBX is because both SDK and the format are really robust.For example ,in FBX you can embed not just geometry and animation but also scene objects as lights ,cameras etc.Autodesk docs are very nice too.
Hope it helps.
I would reccomend using your own custom format that basically just a binary dump of the vertex buffer and index buffers used in your program. (Using d3d terms there, I know opengl has the same concepts but can't remember if they have different names).
I would then write a separate program using assimp that takes pretty much any format and writes out the file in your custom format. Then you can use collada or whatver to store your actual models in, but not have the complixity and slowness of loading that format at run time.
I like to print a document. The content of the document are tables and text with different colors. Does a lightwight printer-file-format exist, which can be used like a template?
PS, PDF, DOC files in my opinion are to heavy to parse. May there exist some XML or YAML file format which supports:
Easy creation (maybe with a WYSIWYG-Editor)
Parsing and manipulation with Library-Support
Easy sending to the printer (maybe with Library-Support)
Or do I have to do it the usual way and paint within a CDC?
I noticed you’re using MFC (so, Windows). In that case the answer is a qualified yes. In recent versions of Windows, Microsoft offers the XPS Document API which lets you create and manipulate a PDF-like document using XML, which can then be printed using the XPS Print API.
(For earlier versions of Windows that don’t support this API, you could try to deal with the XPS file format directly, but that is probably a lot harder than using CDC. Even with the API you will be working at a fairly low level.)
End users can generate XPS documents using the XPS print driver that is available for free from Microsoft (and bundled with certain MS products—they probably already have it on their system).
There is no universal language that is supported across all (or even many) printers. While PCL and PS are the most used, there are also printers which only work with specific printer drivers because they only support a proprietary data format (often pre-rendered on the client).
However, you could use XSL-FO to create documents which can then be rendered to a printer driver using library support.
I think something like TeX or LaTeX (or even troff or groff) may meet your needs. Google them and see.
There are also libraries to render documents for print from HTML source. Look at http://libharu.sourceforge.net/ for example. This outputs a printer-ready .PDF
A think that Post Script is a really good choice for that.
It is actually a very simple language, and it must be very easy to parse becuse it is stack-oriented. Then -- most printers supprort it, and even if you have no support you can use GhostScript to convert for many different formats (Consider GS as a "virtual PS supporting printer").
Finally there are a lot of books and tutorials for the language.
About the parsing -- you can actually define new variables and functions in PS. So, maybe, your problem can be solved (almost) entirely using PS.
HTML + CSS can be printed -- properly. CSS was designed to support this with the media attribute to specify that your CSS is for printer layout, not for screen layout. Tools like PRINCE (free + commercial versions) exist to render this for printing.
I think postscript is the markup language used by printers. I read this somewhere, so correct me if postscript is now outdated.
http://en.wikipedia.org/wiki/PostScript
For more powerful suite you can use Latex. It will give options of creating templates where you can just copy the text.
On a more GUI friendly note, MS-Word and other word processors have templates. The issue is they are not of a common standard or markup.
You can also use HTML to render stuff in a common markup but it will not be very printer friendly.