OpenGL 4.0 specification
March 11th, 2010The Khronos group just announced the OpenGL 4.0 spec. That’s some major news! I still have to get my hands dirty with geometry-shaders, GPU-tesselation and OpenCL *sigh*
The Khronos group just announced the OpenGL 4.0 spec. That’s some major news! I still have to get my hands dirty with geometry-shaders, GPU-tesselation and OpenCL *sigh*
I finally managed to motivate myself to update OpenGL examples with cairo with the current/new links to the hosting spots, where interested people can grab the example-sources. Over the last couple of weeks I got numerous requests regarding the stale links to the different examples listed on that page.
All examples have been migrated from git to bzr and put on launchpad. You can check out their sources from there. While doing that I also moved the repository of lowfat to launchpad. For lowfat’s code I also got a couple of “Where to grab the code?”-questions in my inbox. So now everybody should be happy and be able to easily get hold of the sources.
Here’s the quick list for the impatient readers:
Since glitz has been deprecated and completely removed from cairo’s source tree I also updated some of the examples, which used glitz-related code. So far I’ve not been able to add support for the new shiny cairo-gl backend, which the new coolness. I started on it, but stuff only segfaults around.
All that took so long because I can hardly force myself to do any spare-time hacking. It’s just not fun anymore, when you sit in front of the computer day in and day out. There are certainly tons of interesting things to do or try, but motivation is just zero.

The first alpha version of blender 2.50 (what will become blender 2.60 once final) is officially out. It is being stress-tested by their user-community and by the artists working on “Sintel” (the newest installment of the OpenMovie-series by the blender foundation).
I’m really looking forward to this new short, even more than I anticipated the last two ones. Because this time around I, or rather the martial-arts team I’m a member of (banGang), is going to help out the creative minds behind “Sintel” with fighting, acrobatics, stunts and reference footage.
I’m leaving for Texas, USA soon. Me being a German living in - guess - Germany, causes the need to apply for the US “Visa Waiver Program” using https://esta.cbp.dhs.gov (thanks again to Otto for reminding me *g*) these days. While clicking through and filling out the forms of the electronic variant of that “green sheet of paper” (the one you used to have to fill out on the plane prior to landing on US soil) I was greeted by this notice…

It’s almost 2010! Have the people, who implemented that web-interface, ever heard of Unicode or do they expect international travelers to not use anything but ASCII to supply their (usually non-english) names, which carry the high probability with them to not use ASCII characters only? For me it’s just the ü in my surname. I wonder what people with funkier names do, when they have to diverge from the correct name-spelling to something this ESTA-system accepts. Once they succeed there, I bet they have a hard time trying to convince the staff at customs, that they are really themselves, because the spelling of their name on the passport doesn’t even remotely match the spelling in the visa-waiver-form.
I once almost wasn’t let aboard a plane in Germany, because the travel-agency booked my flight on “Mueller”, but my passport says “Müller”. Is all that the legacy-fault of Cobol?
… so… I wrote my first particle-system ever. It does not look photorealistic - by far not *g* - but implementing something like that is great fun! You see a cluster of 5000 particles in the screencasts below. Right now I’ve two emitters (a “singularity” one and a rectangle one) with a gravity force-field being applied to the particles. WASD/Quake-like camera-navigation I implemented too, so one can “walk around”. From here numerous things could be added: wind, general turbulence, attraction-/repulsion-forces between particles, collision-detection with obstacles… the visualization could be improved with motion-blur, lighting, shadows etc. Rendering- and simulation-loop are coupled and run at 60 Hz. Screencasts were recorded with 30 Hz.
Someone not so familiar yet with living in the OpenSource realms asked me why we constantly push for free drivers (graphics drivers in particular) as much as we can. Apart from “with enough eyes all bugs are shallow” (famous quote from L. Torvalds) and making the user more independent from a hardware vendors fate, protection from cheating is another good reason for our attitude. In the referenced article it is demonstrated how a vendor does benchmark-specific optimizations to obtain better results in those and thus positively, but incorrectly, manipulates review-results for their product. Within the world of OpenSource Xorg/DRI-drivers this cannot happen. So to speak xorg-video-ati/intel/nouveau are more honest towards the user than fglrx and nvidia-glx (speaking in Debian/Ubuntu package-name terms here) are. In all fairness I want to mention that fglrx and nvidia-glx provide more complete and robust support for OpenGL and its extensions, when compared to the OpenSource counterparts. Still, looking at my own experience with them, I like the way xorg-video-intel and xorg-video-ati are going in recent times.
Fixed the throbbing animation for over- and undershooting of the value indicator in notify-osd: