glCapsViewer 0.5 + SQL database

I’ve just released version 0.5 of glCapsViewer, and though the tool itself doesn’t seem that much different from 0.4, the real difference is in what’s behind it. Cause I’ve dropped the simple PHP listing (and searching) of uploaded XML files in favour of a real SQL database. This is not only much faster but allows for a lot of new features, and one these first new features (and propably one of the most important) is the possibility to compare (up to eight) reports in a single page. So you can quickly check their limits as well as what report supports what extension.

Note that I have migrated the old XML-reports into the new database, so if you already uploaded them with one of the old versions there is no need to re-upload. As usual you can access the database here.

glCapsViewer 0.5 + SQL database

glCapsViewer – OpenGL capability viewer + online database

If you’re creaing OpenGL apps (no matter if games, apps or demos) that you want to distribute, you often get error reports from user with the oddest things happening on their systems. Recently I distributed a benchmark for “Phase 2” to some people and after hours of trying to get it working for everybody I noticed that some of the testers had graphics cards that supported shaders (vertex and fragment) but no framebuffer objects, a pretty odd combination.

Back in the days (several years ag)o Tom Nyudens from (don’t go there, it’s no longer online) had a tool that read out an OpenGL’s implementation details (extensions, max values, etc.) and would store them online so every developer could go there and check what graphics card had which OpenGL capabilites. But sadly that tool along with the database went off when the site went down long time ago.

So I decided to end this deficit by creating such a tool by myself, simply named glCapsViewer. It doesn’t only read out all important OpenGL implementation details but is also able to upload them to a preliminary “database”, so developers can easily check out OpenGL implementation properties online. You can check out the preliminary database over here (not much in there yet, but that’ll hopefully change soon). Feel free to upload your own reports (but please for real hardware only, no need to upload a report for e.g. virtual box GL implementations or MESA) but note that I plan on doing a real database (the current one is just a list generated by the XML reports that have been uploaded) so at some point that database may be wiped (though I hope to integrate the files into the new one instead, only if possible).

An yes, some may have noticed that I actually uploaded a first version of it (created in Delphi) some days ago but decided to wait before announcing it to the public until I added another platform, and that’s what I just did, so here is the official announcement. I ported it over to Lazarus (and FPC), installed ubuntu in a virtual box and created a linux port too. So now you can upload reports from Windows and Linux (i386), other plattforms (like Mac OS) may also become available in the future, but don’t count on it. And yes, this is a first for me after ~20 years of coding, my first own application with a linux port. So now that a lot of people asked for linux versions of the apps/demos/games I did hopefully a lot of linux reports will be uploaded.

glCapsViewer – OpenGL capability viewer + online database

Color selection, FBOs and traditional render-to-texture

In what happens to be a rarity nowadays you’ll now get exactly what you could guess from the caption of this posting. I’ve been working on those three things yesterday and today and thought I might share some of my experience implementing color selection the right way into a complex user interface.

Those of you that coding apps/games/whatever using OpenGL might know that the old selection functionality of OpenGL (which wasn’t that bad at all) is a no-go nowadays, mainly due to the fact that it’s done in software for some time now by all big graphics cards vendors and therefore sadly disqualifies it for a realtime usage. In case you never used it : It had a name stack and a special render mode. So before rendering an object you could push a name (actually an integer) onto the name stack, render the object and go to the next object until you’ve drawn all objects that are selectable in your 3D scene. Then you could simply read back what object was drawn at a certain point in your framebuffer and OpenGL returned the name of it.

But nowadays it’s a no-go due to it’s slowness and so I’ve been using a technique called “color selection” for some time now. It’s a manual way of doing selection on your own in OpenGL (or any other 3D-rendering API) that is fast and easy to use but also has it’s caveats, something I’ll be getting to. It basically works by rendering your objects without lights/shaders/textures and only single-colored and then reading back the color below e.g. your cursor and you then compare it to the stored values for your objects so you can easily get the selected object derived from the color read back from the framebuffer below the cursor.
(left image shows the region, right image shows the color selection image) :

It sounds very simple and if you do it in a basic demo it also is very simple. First you render the color selection parts only (not visible to the eye in your backbuffer), read back the color, get the object selected, clear the scene and then render your normale scene. This works fine for simple cases. But ProjektW is not a simple case.

But take a look at this :

It’s a bit hard to see. But this is a construction spot in the regional view of “Phase 2”. You see a crane with an alpha-masked texture that lets the background “shine” through. And now you also see that the upper part has a red background. And that is one of the aforementioned problems when using color selection in e.g. a complex UI like “Phase 2” does. Why? Because the window has a callback for rendering the content that is called when the window is visible and in that callback I render (amongst other stuff) the region’s structural preview with all it’s building spots. And So contrary to a simple application I can’t just render the color selection view of the region and delete the framebuffer’s content cause that would erase the whole content of the window that was drawn before (e.g. the background scenery image).

So how do you get around these problems? You need to use some kind of offscreen rendering. For “Phase 2” I use frame buffer objects when available (if not, just simple render-to-texture). Though here lies another problem that forced me to change how I update the offscreen rendering in “Phase 2”. When you use FBOs you can update them whenever you want, cause your normale framebuffer won’t be affected. But with normal render-to-texture that’s not the case, so you can’t just simply update the texture when e.g. the region is displayed cause that would affect the current framebuffer too, but along with this problem I fixed the above color selection problem too : I do texture (and fbo) updates and color selection before I start rendering the current frame, and that fixes all those problems.

Old way of updating textures and doing color selection :

  • Render the 3D-Scene in the background (globe, water, sky)
  • Render GUI
  • GUI calls the region’s window’s callback for content rendering
  • Color selection view of region is rendered
  • Depth buffer is cleared
  • Normal view of region is rendered
  • This would cause the above artefacts behind alpha-masked (and translucent) buildings and also would not work with normal render-to-texture (since I want to have an audience as broad as possible I implemented that for older GPUs).

    So here is how the rendering now looks :

  • Update (if necessary ) FBO (or texture) for region’s normal view
  • Update (if necessary ) FBO (or texture) for region’s color selection view (yes, separate FBOs/textures, cause it’s not always necessary to update them both, this is due to performance reasons)
  • Render ONLY the color selection part of the region if the window is visible and cursor is hovering above the 3D preview panel
  • Read back color in framebuffer and get selected building
  • Clear framebuffer (and depth, stencil and everything else)
  • Render the 3D-Scene
  • Render GUI
  • GUI calls the region’s window’s callback for content rendering
  • Now just paint a simple quad with the FBO/texture of the region’s normale view where the 3D panel is located
  • So now with that new way of rendering e.g. the region there are no more artefacts for the color selection of alpha-masked buildings and (not less important) it’s now a lot faster cause I only update the FBO/texture of the region’s view when something has changed instead of rendering the region directly onto the GUI every frame. Hopefully this will help some of you on how to render 3D scenery on-top of a 2D user interafce, as it’s not a trivial task.

    Color selection, FBOs and traditional render-to-texture