VS*L has been updated to allow cube maps to be loaded as textures. Tangents and bitangents are also provided for every loaded model. The models default texture, the texture definitions of the loaded model, can now be replaced by any pre loaded texture.
VSMathLib, a part of the Very Simple Libraries framework, has suffered a minor update. The modelview matrix has been split into two matrices: model and view. The modelview matrix is still available, but now it is a computed matrix. The programmer should use the two individual matrices, model and view, and the lib will compute the modelview, actually called VIEW_MODEL, as required.
The PROJMODELVIEW has been renamed to PROJ_VIEW_MODEL since this is the actual order of the matrix multiplication.
Besides that the lib works as usual. Comments are most welcome as usual.
A sample using all the libs in the Very Simple framework is now available from the VS*L downloads page. The sample source C code, shaders, a 3D model, and textures, are provided, as well as a Visual Studio 2010 solution.
Very Simple OpenGL Information Lib – OpenGL has a rich set of functions to query its state. It is possible to get information on just about anything, from which shaders are attached to a program, to the values of uniforms, or the properties of the textures currently bound.
However, it is also true, that to get some of this information a lot of code is required. When debugging, we end up writing code to access this and that information over and over again.
This lib attempts to provide all the information with a minimal effort to the developer, for textures, buffers, GLSL programs, shaders, and variables, and a few more items.
Christophe wrote an excellent call for bug reports on the OpenGL, GLSL and extension specs.
“Getting OpenGL implementations better is not only the duty of implementers but also of the OpenGL programmers. There is something worse than a bug: there is an unknowned bug.”
One of the bugs reported in here has been corrected. The uniform buffer data size is now reported correctly.
The other two bugs remain, unfortunately. Querying the primitive counter still gives zero, and glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS_ARB) still crashes the application.
Two more libs are available in the VS*L framework. With these new additions it is possible to use Assimp to load 3D models, and render them with core OpenGL. The libs store the meshes in VAOs, and use VSShaderLib and VSMathLib to simplify the rendering with shaders with almost any uniform variable configuration.
VSML has been renamed to VSMathLib. Too many libs in the pipeline to keep naming them with a single letter 🙂
The M stood for Matrix, yet as now the library also contains vector operations, I think the new name fits better with the content.
Another addition is the availability of the normal and projection-view-model matrices. These are commonly used in shaders, and it doesn’t make sense to keep computing it for every vertex.
Finally, the lib now works with the VSShaderLib to provide a more general method for uniform variable settings.
Bug reports are most welcome.
Shaders are the core of the rendering process. OpenGL core profile requires us to provide our own shaders, no more fixed function.
Using shaders means more flexibility, but it also implies more work. This is where this lib steps in.
VSShaderLib was designed to make our life easier. It allows to create programs, load shaders from files, associate vertex attribute names with locations, and work with uniforms, including uniforms in named blocks. It also provides access to the info logs.
I don’t know where to put this. I’ve tried the AMD forum but got no reply. So here goes:
I’ve only tested this on Windows 7 64 bits. Anyone with different/same results on same or other systems?
– ARB Debug Output Extension
When not in debug mode the following instruction causes an Access Violation in Visual Studio:
glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS_ARB);
This only occurs when not in Debug OpenGL context and it does not cause any problem with nVidia hardware.
I’ve not tried it with Linux yet.
– Uniform Buffers
Consider a uniform block declared as follows:
layout (std140) uniform Matrices {
mat4 modelviewMatrix;
mat4 projModelViewMatrix;
mat3 normalMatrix[2];
};
This is what I get when I use glGetActiveUniformsiv to retrieve info on the block:
Matrices, Binding: 2 Datasize: 320 ActiveUniforms: 3 Referenced by: TessEval Shader(s) modelviewMatrix 1 16 mat4 0 normalMatrix 2 16 mat3 128 projModelViewMatrix 1 16 mat4 64
The data for each uniform is size, matrix stride, type and offset.
My problem lies with the size of the buffer. AMD’s driver claims, as shown above, that the size is 320, but in reality it is 224 (nVidia reports the right value), considering the reported matrix stride of 16. The math is pretty simple:
16×4 = 64 bytes for each 4×4 matrix times 2 = 128
16×3 = 48 bytes for each 3×3 matrix times 2 = 96
Total = 128 + 96 = 224.
Strangely enough, if I define the normalMatrix as an array with 3 mat3 (so one more than previously), I get a reported data size of 464.
I’ve tested several possibilities to set one of the mat3 without success. With nVidia it works OK . The only difference in the information reported, besides the data size, is the name of the normalMatrix uniform, that nVidia chooses to call it normalMatrix[0].
– Querying the primitive counter
I always get zero! Again works nicely in nVidia.