Is there a way i can debug a glsl shader? including like breakpoints and data tracking
i seen simple ones that let me see what shaders make my shade programs but nothing i can put break points in.
I need to check out values of matrices and just throwing a glFragColor will not work since there's so many values to be compared and checked.
is there a simple way of doing this? besides me just writing down what values i think i might have and doing my math out else where.
it's really annoying when I'm trying to understand all of OpenGL and knowing how to navigate around DirectX. I can see why some people get scared away from OpenGL when resources get hard to find.
According to the development updates for NVIDIA Nsight, they recently added features for GLSL debugging (https://developer.nvidia.com/nsight-visual-studio-edition-3_0-new-features). I would look there first. Also glslDevil (http://www.vis.uni-stuttgart.de/glsldevil/index.html) looks good. I haven't tried either program myself, so can't give first hand experience about quality. I have been impressed by NVIDIA's support for debugging in CUDA though, so have high expectations.
Related
I'm trying to replicate the effect of Cathode but i'm not really aware of any rendering effects in SDL. Does anyone know the technique used in Cathode? Are they using OpenGL and shaders maybe?
If you are still interested in the subject I'm working on a similar project. The effects were obtained by using GLSL shaders.
You can grab the source code here: https://github.com/Swordifish90/cool-old-term/
The shaders strings might not be extremely readable due to the extensive use of the ternary operators (needed to customize the appearance) but they should give you a really good idea.
If you poke around a bit in the application bundle, you'll find that the only relevant framework is GLKit which, according to Apple, will "reduce the effort required to create new shader-based apps".
There's also a bunch of ".fragdata", ".vertdata", and ".glsldata" files, which are encrypted.
Very unfortunate for you.
So I would say: Yes, it's OpenGL shaders all the way.
Unfortunately, since the shaders are encrypted, you're going to have to locate suitable algorithms elsewhere.
(Perhaps it's possible to use the OpenGL debugging and profiling tools to capture the shader source as it is compiled, but I doubt it.)
You may have realized that Android phones have (had?) such animations when you put them to sleep. That code is available under in file named ElectronBeam.java.
However it is Java code and uses GLES 1.0 with GLES 1.1 Extenstions but algorithm for bending screen should be understandable.
Seems to be based on GLTerminal which uses OpenGL, it would have to use OpenGL and shaders for speed.
I guess the fastest approximation would be to render the text to buffers within OpenGL and use a deformed 2d grid to create the "rounded corners" radial distortion.
But it would take a lot of work to add all the features that cathode has, not to mention to run them quickly.
I suspect emulating a CRT perfectly is a bit like emulating an analog synth perfectly - hard to impossible.
If you want to work quickly and not killing the CPU, the GPU is the best solution! So pixel shaders. pixel shaders can do all of these effects. Once I made such an application. I wrote it in Silverlight, but it does not matter, I used the pixel shader.
Suggests to write this in Qt4 and add to the QWidget pixel shader effects.
I used glFogCoordEXT to distinguish explored and unexplored terrain. But after i use a shader for normal mapping on terrain, its working fine but the fog is no more there.
can some one help me, (i don't know glsl).
I think you used the fixed-function-pipeline before? By using a custom pixel-shader you "overwrite" the fixed-function-pipeline. You have to manually add fog to your pixels inside the normal-mapping-shader, but that is difficult without any knowledge of GLSL. You may try googeling for GLSL fog, there are plenty of fogging-functions for GLSL that work with the built-in variables (which are edited by glFogCoord). You can then try to wire this function into your normal-mapping-shader. Read a tutorial about vertex/pixel shaders before, they are not that hard to understand. Shaders are just mathematics, the language itself is much easier than the C++ code of the actual program.
Background
I work on the game Bitfighter. We're still compatible with OpenGL 1.1 and compile for OSX, Windows, and Linux.
We use vector graphics for everything, including text rendering and manipulation. We use a slightly-modified variation of 'FontStrokeRoman' from GLUT, which is just a bunch of static lines. We like this as it seems to perform very well, easy to rotate/scale/manipulate. We also allow for in-game chat so text is drawn on the fly.
Problem
We want to use more/different fonts.
We've found several other fonts we like, but they are all TTF-type fonts that are built as polygons (with curves, etc.) instead of strokes or spines. This brings up a few problems:
We'd have to use textures (which we've avoided so far in the game)
They're not easily resizable/rotatable/etc.
Performance is significantly less (theoretically?)
We've experimented with converting the TTF fonts to polygon point arrays and then triangulating the fill. This however has been difficult to render nicely - pixel hinting/anti-aliasing seems difficult to do in this case.
We've even experimented with skeletonize-ing the polygon fonts using libraries like 'campskeleton', so we can output a vector-stroke font (with not much success that looks good).
What should we do?
I know this question is somewhat general. We want to keep performance and text manipulation abilities but be able to use better fonts. I am open to any suggestion in any direction.
Some solutions could be answers to the following:
How do we properly anti-alias polygon-based text and still keep performance?
Do textures really perform worse than static point arrays? Maybe I have a faulty assumption
Can textured fonts be resized/rotated in a fast manner?
Something entirely different?
After some convincing (thanks Serge) and trying out several of the suggestions here (including FTGL that uses freetype), we have settled on:
Font-Stash which uses stb_truetype
This seemed perfect for our game. Rendering performance was comparable to the vector-based stroke font we used - textured quads really are not that slow, once generated, and the caching from Font-Stash helps immensely. Also, the use of stb_truetype allowed us to not require another dependency in the game across all platforms.
For what its worth, this solution was roughly an order of magnitude faster than using FTGL for true-type fonts, probably because of the caching.
Thanks for the suggestions and pointers.
Update
The Font-Stash link above was a fork of the original here. The original has since been updated, has added some of the features that the fork, and can allow different rendering back-ends.
I'm no OpenGL expert, or graphical expert in general.
And, really, Raptor, I -hate- to be the guy that says this, because I know how you feel right now.
I really hate to say it, but honestly, I'd just give TTF fonts a shot, using their textures and polygons as they were intended. I doubt that such a usage would truly be detrimental towards your performance these days. It would likely be more valuable to save time to use them as is, rather than spending time to experiment around for some clever solution that more fits your desires.
I doubt that text drawing using polygons/textures would be detrimental, whatsoever, to you performance. This especially applies for today's computers. How many years back, technologically, do you intend on supporting with your application? Or perhaps you wish to run it on the Raspberry PI as well? Or other mobile platforms that do not have high graphical capabilities? Support of any of these could, perhaps, invalidate my claims.
But, like I said, I really hate to be the guy that suggests you to trudge forward as is. Because, I've been there, asking for performance advice (sometimes over even tinier things) and just groaning when someone says 'forget about it, the compiler will handle it' or 'computers are so advanced you shouldn't worry about it'. I honestly hope that someone else comes in with experience, and a good answer for you. However, if not, I just want let you know: I cannot foresee the possibility that using TTF, as it was intended, would be detrimental whatsoever to your gameplay performance.
Did you try outline glyph decomposition using freetype FT_Outline_Decompose ?
Freetype is the tool of choice for font rendering and glyph outlines extraction. Hinting is supported and rendering modes allows you to specify that you want antialiazing, hinting, monochrome targets etc.
Freetype also has a built in glyph/bitmaps cache mechanism which may be useful.
Note : OGFLT seems to bridge the gap between freetype and opengl although I never has the chance to use it
I used opengl 2 years ago. In one afternoon I read a tuto, I drew a cube (and then learned how to load any 3d model) and learned home to move the camera around with the mouse. It was easy, less than 100 lines of codes. I didnt get the pipeline completely but I was able to do something.
Now I need to refresh opengl for some basic stuff, basically I need to load a 3D model (any model) and move the model around, with the camera fixed. Something I thought would be another afternoon.
I have spent 1 day and have nothing working. I am reading the recommended tuto http://www.arcsynthesis.org/gltut/ I dont get anything, now to draw just a cube you need a lot of lines and working with lots of buffer, use some special syntax for shaders.... what the hell I only want to draw a cube. Before it was just defining 6 sides.
What is going on with opengl? Some would argue that now is great, I think it is screwed.
Is there any easy library to work with Something that would make my life easier?
GLUT - http://www.opengl.org/resources/libraries/glut/
ASSIMP - http://assimp.sourceforge.net/
These two libraries are all you need to make a simple application where you import a model (various formats). Read it's documentation and examples to get a better understanding on how you can "glue" OpenGL and ASSIMP to work.
Documentation
As to is OpenGL more hard to comprehend? No. What I've learned in recent years from OpenGL is that GFX programming is never simple or done in a few lines of code, you have to be organised, you have to be careful and even a simple primitive (e.g cube) needs to have more than 100 lines of code to make it decent and flexible (for example if you want more subdivisions on your polygons or texturing).
If you learned it only two years ago, then the tutorials were extremely outdated. Immediate Mode has been known to be deprecated for a very, very long time. Actually the first plans to abandon it and display lists date back to 2003.
Vertex Arrays have been around since version 1.1, and they have been the preferred method for sending geometry to OpenGL ever since; in immediate mode every vertex causes several function calls, so for any seriously complex object you spend more time managing the function call stack, than doing actual rendering work. If you used Vertex Arrays consequently since their introduction, switching over to Vertex Buffer Objects is as complicated as just inserting or replacing a few lines.
The biggest hurdle using OpenGL-3 is in Windows, where one has to use a proxy context to get access to the extension functions required to select OpenGL-3 capabilities for context creation. However again no big hurdle, 20 lines of code top. And some programs, like mine for example, create a proxy GL context anyway, to which all shareable data is uploaded, which allows to quicly destroy/recreate visible contexts, yet have full access to textures, VBOs and stuff (you can share VBOs, which is another reason for using them instead of plain vertex arrays; this might not look like something big, at least not if the context is used from a single process; however on plattforms like X11/GLX OpenGL contexts can be shared between X11 clients, which may even run on different machines!)
Also the existance of functions like the matrix manipulation stack led people into the misconception, OpenGL was some matrix math library, some even believed it was a particularily fast one. Neither is true. The removal of the matrix manipulation functions was a very important and right thing to do. Every serious OpenGL application will implement their very own matrix math anyway. For example any modern game using some kind of physics engine used to directly use in OpenGL (glLoadMatrix, or glUniformMatrix) the transform matrix spit out by the physics calculation, completely bypassing the rest of the matrix functions. This also means that the sole reason to have multiple matrix stacks (GL_PROJECTION, GL_MODELVIEW, GL_TEXTURE, GL_COLOR), namely being able to use the same set of manipulation functions on several matrices, was obsoleted and could have been replaced by something like glLoadMatrixSelected{f,d}v(GLenum target, GLfloat *matrix). However Uniforms and shaders already were around, so the logical step was not introducing a new function, but to reuse existing API, which had been used for this task already, anway, and instead remove what's no longer needed.
TL;DR: The new OpenGL-3 API greatly simplyfies using it. It's a lot clearer, has fewer pitfalls and IMHO is also more newbie-friendly.
You don't have to use buffer objects. You can use the deprecated immediate mode. It will be slower, but if you don't really care then go ahead and use OpenGL the way you used to. NeHe has some excellent tutorials on OpenGL 1.x stuff.
Swiftless has some good tutorials (only a few very basic ones) on OpenGL 3.x and 4.x, but the learning curve is, as you've found, very steep.
Does it have to be openGL? XNA offers an ability to draw 3d models without breaking your back.. Could be worth a look
I've recently been doing some DirectX 10 work and I'm looking to move to DirectX 11 and Shader Model 5.0. I've written a few very simple shaders in the past and I'm looking to broaden my horizons and venture into more complex shaders. My question is sort of multi-fold:
What is the best tool out there to program shaders with? I've only used visual studio and SOME FX composer - read: enough to open it up and look at it.
Does the brand of gfx card effect what type of shaders you can program?
The reason I ask is that it seems like Nvidia has way better tools and ATI seems to have cancelled RenderMonkey. I don't seem to see any replacement for it? Am I wrong?
Sort of the same question as #1, but can you use cross vendor tools if you just intend to write DirectX shaders and not vendor specific?
If you need to go vendor specific, does Nvidia generally have better tools? I'd really like to ATI right now, as they seem to be the best bang for the buck (and I have an AMD board) - but am hesitant becasue I mostly use my gfx cards for programming.
What is your ultimate goal? If you'd just like to know a little more about shading, or if you are an artist or technical artist, then 1. FX Composer and RenderMonkey are pretty good.
If you are a programmer and you'd like to make graphics engines, then 1. you should use a text editor, because the shader is just one small part of a graphics engine. Past a certain low level of sophistication, shader constants and certain textures need to be created on-the-fly in a language like C++.
two. The brand of graphics card doesn't affect what kind of shaders you can program at all nowadays.
three. Cross-vendor tools are fine.
Though you didn't address this issue in your question, I feel I should mention: not only are shaders today just a small part of a graphics engine, but their role will diminish soon as focus shifts to deferring work until "post-processing" using "compute." A shader will soon typically output abstract terms like albedo and normal, not color. Its relevance to art will decline.