°
°
°
°
°
°
Creative
Technical
°
°

Latest posts

/ Technical / Latest posts >>

°
°

GLM FAQ

/ Technical / Content / Projects / GLM >>

As part of GLM 0.9 development, I am rewriting the manual which include a FAQ. This is what I currently get, if you have more ideas don't hesitate to submit!

1. Why GLM follows GLSL specification and conventions?

Following GLSL conventions is a really strict policy of GLM. GLM has been designed following the idea that everyone does its own math library with his own conventions. The idea is that brilliant developers (the OpenGL ARB) worked together and agreed to make GLSL. Following GLSL conventions is a way to find consensus. Moreover, basically when a developer knows GLSL, he knows GLM.

2. Why vec4(x) * y doesn't build?

GLM follows GLSL semantic conventions and features. Indeed, a vector by a scalar product is supported. However, GLSL defines for example a vector of float by a float scalar but doesn’t support for example a vector of float by a double scalar. Value types must match.

  • vec4 v1;
  • vec4 v2;
  • dvec4 v3;
  • float s1;
  • double s2;
  • ...
  • v2 = v1 * s1; // OK
  • v2 = v1 * s2; // ERROR
  • v3 = v3 * s2; // OK
  • v2 = v1 * 2.0f; // OK
  • v2 = v1 * 2.0; // ERROR
  • v2 = v1 * 2; // ERROR

3.3. Would it be possible to add my feature?

YES. Every feature request could be added by submitting it here: https://sourceforge.net/apps/trac/glf/newticket

These requests would mainly take the form of extensions and if you provide an implementation, the feature will be added automatically in GLM release.

3.4. Does GLM run GLSL program?

No, GLM is a C++ implementation of a subset of GLSL.

3.5. Does a GLSL compiler build GLM codes?

Not directly but it can be easy to port. However, the difference between a shader and C++ program at software design level will probably make this idea unlikely or impossible.

3.6. Should I use GTX extensions?

GTX extensions are qualified to be experimental extensions. In GLM this means that these extensions might change from version to version without restriction. In practice, it doesn’t really change except time to time. GTC extensions are stabled, tested and perfectly reliable in time. Many GTX extensions extend GTC extensions and provide a way to explore features and implementations before becoming stable by a promotion as GTC extensions. This is fairly the way OpenGL features are developed through extensions.

3.7. Would it be possible to change GLM to do glVertex3fv(glm::vec3(0))?

It's possible to implement such thing in C++ with the implementation of the appropriate cast operator. In this example it's likely because it would result as a transparent cast. However, most of the time, it's really unlikely resulting of build with no error and programs running with unexpected behaviors.

GLM_GTX_type_ptr extension provide a safe solution:
  • glm::vec4 v(0);
  • glm::mat4 m(0);
  • glVertex3fv(glm::value_ptr(v));
  • glLoadMatrixfv(glm::value_ptr(m));
Another solution inspired by STL:
  • glm::vec4 v(0);
  • glm::mat4 m(0);
  • glVertex3fv(&v[0]);
  • glLoadMatrixfv(&m[0][0]);

3.8. Where can I ask my questions?

A good place is the OpenGL Toolkits forum on OpenGL.org: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=postlist&Board=10&page=1

3.9. Where can I report a bug?

Just like feature requests: https://sourceforge.net/apps/trac/glf/newticket

3.10. Where can I find the documentation of extensions?

The Doxygen generated documentation includes a complete list of all extensions available. Explore this documentation to get a complete view of all GLM capabilities! http://glm.g-truc.net/html/index.html

Send a comment - 09/03/2010
°
°

Using sRGB color space with OpenGL

/ Technical / Content / Articles >>

sRGB is a non-linear color space that can be directly displayed by computer display devices. Another very popular color space is Adobe RGB often used in photography for its higher precision. sRGB and Adobe RGB color spaces define what actual color is a color code so that on all compatible outputs or supports, the color will look the same.

OpenGL defines sRGB textures (OpenGL 2.1) and sRGB framebuffers (OpenGL 3.0) to take advantage of the sRGB color space. sRGB provides an optimized use of each value of the storage range so that these values become more relevant for our eyes perception. A quality gain for zero extra storage.

OpenGL provides sRGB with 8 bits components and compressed sRGB data only. These formats are identified with GL_SRGB, GL_SRGB8, GL_SRGB_ALPHA, GL_SRGB8_ALPHA8, GL_COMPRESSED_SRGB and GL_COMPRESSED_SRGB_ALPHA. When the extension GL_EXT_texture_compression_s3tc is supported, the following format are supported: GL_COMPRESSED_SRGB_S3TC_DXT1_EXT, GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT and GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. These formats are absolutely similar to the usual DXTC1, DXTC3 and DXTC5 but with sRGB sources.

The ARB has considered that less that 8 bits per pixel is not enough precision to make a non linear color space relevant for storage. The ARB has also considered that more than 8 bits per pixel is so much precision than sRGB isn't really useful. Another way to see this, is that less than 8 bits per pixel is not used anymore and more than 8 bits per pixels conversion to linear space would be too expensive to do on the hardware. Currently, we can expect the conversion to be implemented in GPUs with a lookup table of 256 values so that this conversion is almost free to perform. However, a table with 65536 values is a lot higher transistors cost. I would not be surprised to see sRGB16 OpenGL extension in the future.

With OpenGL 3.2 core profile, there is no 1 or 2 components sRGB textures. With OpenGL 3.2 compatibility profile we have some extra formats: GL_SLUMINANCE, GL_SLUMINANCE8_ALPHA8, GL_COMPRESSED_SLUMINANCE and GL_COMPRESSED_SLUMINANCE_ALPHA. One example where nVidia is right about "some deprecated OpenGL features might be useful" (minute 23).

When an alpha channel is used, the alpha channel ALWAYS remains linear. The texture format names use a separated token 'ALPHA' to show this difference between channels.

sRGB is not a linear color space. If we have 2 sRGB pixels A and B then A + B is not a valid operation. Each time a sRGB value is used for an operation, the value need to be converted to a linear color space value. To convert a 8 bits sRGB pixel to a linear RGB pixel, the graphics card might need 16 bits per channel to be lossless.

On the OpenGL pipeline we will find these conversions for three tasks: texel sampling, multisample resolution and blending. OpenGL gives control of these conversions only at blending stage with the calls glEnable(GL_FRAMEBUFFER_SRGB) and glDisable(GL_FRAMEBUFFER_SRGB). When enabled, the values are linearized prior to their use for blending. A lack of conversions will generally darken the framebuffer.

For texel fetch and multisample resolution, these conversions are performed automatically but the way it's performed is just a recommandation. For texel fetch, the recommantation is to perform the conversions to a linear space before the filtering. For the multisample resolution, the recommanration is to perform the conversions before the average.

sRGB textures are supported from GeForce 6 and Radeon 9***. sRGB framebuffers require a GeForce 8 or a Radeon HD 2***. Apple drivers doesn't support OpenGL 3.0 yet (in MacOS X 10.6.2) but supports GL_EXT_texture_sRGB and GL_EXT_framebuffer_sRGB for all cards that support sRGB color space. Intel drivers are also suposed to support both sRGB textures and framebuffers... I'm so sure either about S3. Chrome 4** supports sRGB textures and are suposed to support sRGB framebuffers because S3 claims that Chrome 4** are OpenGL 3 cards but GL_EXT/ARB_framebuffer_sRGB isn't in the extension list of the card.

Unfortunatly, OpenGL ES 1 and 2 don't provide any support of sRGB.

To get started with using sRGB with OpenGL, the last release of the OpenGL 3 Samples Pack contains a sample using a sRGB framebuffer object.

sRGB +:
  • OpenGL and Direct3D support.
  • Compressed textures support.
  • Defines which color a set of values represent.
  • Same storage size than RGB for higher quality.
  • Great LDR format when use with HDR rendering.
  • Large support by tools (Photoshop, Lightroom, Paint Shop Pro, etc.) and hardware (GPUs, Cameras, Monitors, etc.).
sRGB -:
  • Arithmetic operations are not correct without conversion to a linear format.
  • Lower precision than Adobe RGB.
Send a comment - 04/03/2010
°
°

OpenGL Overload (GLO) announcement

/ Technical / Content / Projects / GLO >>

OpenGL Overload (GLO) is new project I am working on.

I have been thinking of replacing GLEW for a while. Unfornunatly, GLEW isn't well maintained and lack of some fonctionnalities such project could provide.

The goal of GLO is first to provide a loading of the OpenGL implementation on Windows (probably OpenGL 3.2 core for the moment). The second point is to provide some kind of debugging fonctionnalies. When enabled, each OpenGL function will be automatically checked and return a message in case of any issue. Finally, a third objective is to provide a basic C++ wrapper.

I expect to release a first version as soon as it can replace GLEW in the OpenGL 3 Samples Pack.

Send a comment - 02/03/2010
°
°

OpenGL 3 Samples Pack 1.3.0 released

/ Technical / Content / Samples / OpenGL 3.x Samples >>

This new version adds a new sample about sRGB textures and sRGB framebuffer. I will add a post about sRGB soon.

I have also updated a lot of samples to fix various bugs on nVidia, ATI hardware and also a lot of work due to a bug in GLEW with recent nVidia drivers. I'm considering (again) loading OpenGL implementation myself...

Send a comment - 27/02/2010
°

On our way to OpenGL 3.3 and OpenGL 4.0?

/ Technical / Comments / OpenGL >>

Between the 9th and 13th of March, the major game developer conference, the GDC 2010 will take place in San Francisco. Last year, GDC 2009 was the event where OpenGL 3.1 was announced. My little findger tells me that we can expect OpenGL 3.3 or at least some ARB extensions to be released this year. With this post, I am dealing with what will could expect for the future OpenGL specifications.

nVidia has released a really interesting presentation with audio at GPU Technology Conference about OpenGL. Three different speekers for three different topics. Barthold Lichtenbelt about OpenGL strategy and Shader Model 5, Mark Kilgard about OpenGL 3.2 and nVidia developments and Michael Gold about OpenGL interopability with other APIs and itself. With such a crew and such topics, I really pay attention to each detail!

Barthold Lichtenbelt, also OpenGL ARB Working Group Chair, gave the ARB discussion feature list for future releases. On top of the list SM5 features support, means D3D11 hardware. On second position there is making GLSL a true superset of GLSL ES. Crossing information, OpenGL ES could become an OpenGL profile like OpenGL core or OpenGL compatibility ... so maybe OpenGL embedded? That's would be absolutely nice! My personnal guess is that OpenGL for D3D11 hardware will be called OpenGL 4.0. This doesn't imply a possible API rewrite, this is so off the table. Beside, I don't believe in changes but in evolutions and on that matter, the deprecation and profiles mechanisiums did great. It's a major jump and this way OpenGL 3.x would remain for SM4 hardware. It makes a lot of sens to me especially because graphics card has tend to be more stable feature wise since SM4 generation. I don't picture any OpenGL embedded profile any time soon.

In this feature list a lot of "oldies" that the OpenGL community is pushing for: Direct State Access, splitting of the texture object into an image and a sampler object, shader binaries, anisotropic filtering. Even if I would love to see it as soon as possible, I don't see Direct State Access or seperated image and sampler objects for OpenGL 3.3... maybe OpenGL 4.0?

Two elements "Use program objects without linking" and "semantics" implies to me a single idea: seperate shader objects. I really don't like this extension but this is definetely where we are going for good reasons: software design and Direct3D compatility. I just don't like the way problems are solved. Basically, developers defined variables could not be used and we should rely on the old and deprecated build-in variables which makes the code absolutely missleading: For example, what the fuck does it means to use a variable called texcoord for a tangent?! Other issue, it introduces a new selector "glActiveProgramEXT" which is absolutely bug prone. Semantics like Cg would allows no linking and no missleading language use as it just introduce some kind of binding points that variable could be attached to. Also, Direct State Access removes selectors. Every elements are here to make it right... findger crossed! I expect this concept to be in OpenGL 3.3.

Last really important part: API interopability which became really important these days because of OpenCL and CUDA but also because of the whole SLI / CrossFire thing. There are considering cross process texture sharing. (why not buffer?) I think it will be in the OpenGL 3.3 train. Some results of this work is probably the recent OpenCL question CL_KHR_gl_sharing. Previous work like the acknowledge WGL_AMD_gpu_association extension or the older WGL_NV_gpu_affinity extension give more clues.

ATI driver 10.2 reports an extension called GL_ARB_blend_func_extended which isn't documented yet. I read here and there that ATI hardware have much more flexible ROPs than what OpenGL or Direct3D exposed but I don't know about nVidia hardware. Is this an atempt to fill this gap? Probably, but I'm quite sure we will have details about it during the GDC 2010. It will definetly give some anwers to people who asked for programmable blending. nVidia has published the great extension GL_NV_texture_barrier which allows to safely write on a binded texture. Probably, a part of this GL_ARB_blend_func_extended extension.

SM5 support? I think it will be with an OpenGL 4.0 release at Siggraph 2010. I expect to see SM5 supports by nVidia with nVidia extensions at GeForce GTX 480 launch end of March. Will we have an OpenGL 3.3 at GDC 2010? What would it be? Answers will be given in 2 weeks!

Send a comment - 25/02/2010
°

Analyse of a XPath query

/ Technical / Comments / XML >>

The version 6 of G-Truc Creation was a great opportunity for to refresh my knowledge of XSLT and XPath.

It's amazing how these two languages are powerfull, a good solution always end up with few code.

  • $Post[./tag[contains(., 'gtc-tech-comment')]][$Count>=position()]

Select $Count first elements of $Post which contains a child element 'tag' which value contains the string-value 'gtc-tech-comment'.

In my real code I prefer to use variable as much as I can so that for example 'gtc-tech-comment' would be replace by one. When an XPath expression is too long I would cut it in several parts. Here $Post[./tag[contains(., 'gtc-tech-comment')]] could be place in a variable. It will also make the code easier to understand in lot of case.

An example of XML code where this XPath code can be applied. $Post is a variable that contains all the 'post' element.

XML example
  • <list>
  • <post>
  • <tag>gtc-tech-content-project-g-truc</tag>
  • <tag>gtc-tech-comment-opengl</tag>
  • </post>
  • <post>
  • <tag>gtc-tech-comment-opencl</tag>
  • </post>
  • <post>
  • <tag>gtc-tech-content</tag>
  • </post>
  • </list>

The result of this query is a set of 2 elements: 'post' elements from line 1 and 5 for every value of $Count greater than 1.

Send a comment - 24/02/2010
°
°

G-Truc Creation 6.3 source released

/ Technical / Content / Projects / G-Truc Creation >>

G-Truc Creation has had a lot of changes for the past few months, actually since the release of version 6. Three updates later, I quite like how it is now and I wish to keep it this way for a while.

Send a comment - 23/02/2010
°

OpenGL tip: Generate mipmaps

/ Technical / Comments / OpenGL >>

Through the years OpenGL has seen three different methods to generate mipmaps. Now days mipmaps are absolutely common and should be used it most of the cases, even bi-linear filtering because it provides both higher performance and higher visual quality for just 1/3 of image memory cost.

The first method is available since OpenGL 1.1 and used to be gluBuild2DMipmaps. It generates mipmaps on the CPU side and automatically calls glTexImage2D for each level just like if the programmer was generating them himself or loading a S3TC texture. A good feature at that time was the capability of gluBuild2DMipmaps to use NPOT textures and convert them to power of two (POT) mipmaps. Until OpenGL 2.0, graphics card didn't had POT 2D textures support beside rectangular textures...

gluBuild2DMipmaps is the solution for convenience but isn't efficient and out dated feature wise. POT can be useful but can't be used anymore and mipmaps generation on FrameBuffer Object is really complicated and inefficient. It would involve copying the texture data from the graphics memory to the main memory and sending it back in the graphics memory... I don't like so much this method but I must admit that it is a really good method for some compatibilities issues with old hardware or OpenGL implementation that doesn't support NPOT textures or doesn't provide other mipmaps generation method. Moreover, at texture loading, this method feats well in a compatibility code path.

OpenGL 1.4 brings the second method with the extention GL_SGIS_generate_mipmap. This method is "hardware accelerated"; the OpenGL API is simple but completely weard because based on a state change using glTexParameter*.

  • glTexParameteri(Target, GL_GENERATE_MIPMAP, GL_TRUE);

A state change for an operation... sound awkward? It is! This call will NOT generate any mipmap. It only says that when a modification to the base level mipmap is done, the lower mipmaps of the base level mipmap shoud be generated. For example, when loading a texture, it means that this previous call should be done before glTexImage2D.

  • GL_GENERATE_MIPMAP can't be used with NPOT if there are not supported by the hardware of GL_ARB_texture_non_power_of_two.
  • GL_GENERATE_MIPMAP can't be used with framebuffer object.
  • GL_GENERATE_MIPMAP doesn't provide a fine control of when the mipmaps should be generated. The best you can do, is disable GL_GENERATE_MIPMAP, update several parts of the texture and enable it just before the last update... awkward.

Finally, but not least, for everyone who is using OpenGL ES 2.0, OpenGL 3.x or hardware supporting GL_EXT_framebuffer_object: glGenerateMipmap!

This function does actually two things which is maybe the only issue with it: It allocates the mipmaps memory and generate the mipmaps. This is very important to notice for framebuffer object texture mipmaps generation because it might reduce render to texture efficiency or simply crash depending if you are using nVidia or ATI OpenGL implementation.

Example of glGnerateMipmap for rendering to mipmapped texture:
  • //Create the mipmapped texture
  • glGenTextures(1, &ColorbufferName);
  • glBindTexture(ColorbufferName);
  • glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 512, 512, 0, GL_UNSIGNED_BYTE, NULL);
  • glGenerateMipmap(GL_TEXTURE_2D); // /!\ Allocate the mipmaps /!\
  • ...
  • //Create the framebuffer object and attach the mipmapped texture
  • glBindFramebuffer(GL_FRAMEBUFFER, FramebufferName);
  • glFramebufferTexture2D(
  • GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, ColorbufferName, 0);
  • ...
  • //Commands to actually draw something
  • render();
  • ...
  • //Generate the mipmaps of ColorbufferName
  • glActiveTexture(GL_TEXTURE0);
  • glBindTexture(GL_TEXTURE_2D, ColorbufferName);
  • glGenerateMipmap(GL_TEXTURE_2D);

On the software design point of view, glGenerateMipmap will make programmers happy as generating mipmaps with it is completely independent from texture modifications.

glGenerateMipmap provides:
  • "Hardware acceleration".
  • Mipmaps generation of Framebuffer Object textures.
  • A fine control of when mipmaps are generated.
  • A great API to use within the OpenGL program.

Finally, OpenGL provides the function call glHint(GL_GENERATE_MIPMAP_HINT, Hint); where 'hint' could be GL_FASTEST, GL_NICEST or GL_DONT_CARE to indicate the quality of filtering when generating mipmaps.

My personal advice would be to use glGenerateMipmap but is need to be available on your platform. From GeForce FX 5*** and Radeon 9*** you will have support for GL_EXT_framebuffer_object or GL_ARB_framebuffer_object with updated drivers. S3 supports GL_EXT_framebuffer_object and OpenGL 3 with its Chrome 430. Apple supports glGenerateMipmap from MacOS X 10.2 and even Intel claims a support. (I would not confirm that one without a test!) If you really need compatibility with old platform, gluBuild2DMipmaps is a great and solid choice.

Send a comment - 21/02/2010
°
°

GLM 0.9 Alpha 2 released

/ Technical / Content / Projects / GLM >>

A new development version of GLM is available. It focus on providing more relevant error messages in case of inapprociate use of GLM.

Send a comment - 20/02/2010
°

Raytracer 1.1 released

/ Technical / Content / Projects >>

To test my current framework, I made an update of my raytracer: It uses GLM and GLI.

More than 2 years since the previous release, the code has changed a bit but feature wise it's basically the same raytracer beside few tricks. Intersection with spheres and plans only, I pay much more attention on materials. I just find it much more fun to play with at the time I did it!

Feature list:
  • Glossy reflexion et reflaction.
  • Adaptative antialiasing.
  • Soft shadows.
  • Procedural materials.
Glossy refraction surfaces
Glossy refraction surfaces
Soft shadows and ... a bug :/
Soft shadows and ... a bug :/

I expect to release a version 1.2 which will support multithreading with OpenMP but also some optimisations allowing the compiler to generate a faster SIMD code. In the end, I will use this raytracer to evaluate Visual Studio 2010 like I did in the past.

Send a comment - 18/02/2010
OGL3 Samples 1.3.0
Technical feed
Copyright © G-Truc Creation 2002-2010 all rights reserved
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥
♥