Read grafman's live report from San Diego.
June 16, 2008
Just posted OpenGL 0.56_04 - the main focus was to switch from GLUT to FreeGLUT
in order to address GLUT limitations involving app-close event handling.
Here are the changes since 5.6_01:
Added OGA calc and affine functions
Added an ATI workaround for GL_ARB_shading_language_100 dependencies
Added VBO and FBO caching in OGAs - gl_util.h
Fixed gluProject and gluUnProject - was converting matrices to ints
Added glutSpecialUpFunc and glutWindowStatusFunc
Added dist option to Makefile.PL to support binary distributions
Switched from GLUT to FreeGLUT
Added FreeGLUT folder for Win32 DLLs
Added glpFullScreen and glpRestoreScreen
Updated test.pl to support Game Mode
Major refactoring of Makefile.PL
Renamed WGL interface option to W32API
Added help message to Makefile.PL
Added verbose option to Makefile.PL
Added documentation comments to OpenGL.xs
Updated test.pl to run texhack if no GLUT
Added a countdown timer to examples/texhack
Fixed GL_X_BYTES in assign
Fixed vertex.glsl to work on newer nvidia cards
Added support for building POGL via cygwin
Note: found some problems with Vista (I believe FreeGLUT-related) - looking into it.
I'm also trying to track down a crash problem involving VBOs on ActivePerl PPM 5.10 -
works fine on 5.8 and 5.6
June 9, 2008
Completed my first iPhone project, using OpenGL-ES. Pulled two straight all-nighters,
and got it out the door at 5:00am Monday morning in time for the Apple conference.
Given that I've yet to even touch an iPhone, much less own one, speaks volumes about
Apple's xcode development environment. Kudos to Apple!
Starting to think about how to BUILD POGL for an iPhone - yes, you can run Perl on an ipHone ;0)
June 5, 2008
Received an urgent contract request yesterday to do an OpenGL project for the iPhone in time for Monday's
Rushed out to buy my first Mac, and to get up to speed on iPhone development.
May 9, 2008
Just tested all my updates on CYGWIN - had to do a lot of gymnastics to get it to build/test
correctly using GLX instead of GLUT. Not sure why the CYGWIN folks insist on using GLX instead
of GLUT - or why they want to build POGL under CYGWIN at all, since the binary PPM distribution
works just fine under CYGWIN.
Anywho - seems to be working. I'll check in these changes after I've tested the PPM 5.10 dist.
May 8, 2008
Threw together a script that generates online docs based on OpenGL.xs comments:
Placed some ads to help defer the cost of maintaining the POGL site - hope it doesn't
tick off too many users.
Let me know if you find it useful.
May 7, 2008
I went through all the openGL.xs code and added comments documenting all the APIs.
I'll use this to generate API documentation for this site - which should make it easier
to use the _p APIs.
While going through the code, I started perusing POGL's GLU implementation. I don't
know who did this, but it's a mess - I don't see how any of the Nurb/Tess/Quad APIs
could possibly work.
If anyone is interested in using these APIs, let me know, and I'll set aside some time
to rewrite them.
May 6, 2008
Spent the past couple of days doing a major refactoring of Makefile.PL - to
reduce its horrendous spaghetti code, and make it a bit more modular, maintainable
and readible. Added a help option, while I was at it.
Also cleaned up utils/glversion to build correctly under Linux. Updated glversion to
report FreeGLUT version. Man, I _love_ FreeGLUT - it's just so much cleaner than
GLUT in terms of window management.
Renamed Chris Marshall's CYGWIN/WGL option to W32API, which better reflects what it's actually
doing: using W32API libs under CYGWIN - it's not exposing any WGL APIs.
Also added dist=NO_EXCLUSIONS by default on Windows - this allows the building of binary
distributions for Windows. This can be overridden by using dist=EXCLUSIONS.
Binary distributions are not currently possible on other platforms, since
there's no support for dynamically loading OpenGL extensions.
May 3, 2008
GameMode and FullScreen modes work as intended on Windows and Mac OS - however,
it's a real mess on Unix:
First, GameMode on X11 systems require the XFree86-VideoModeExtension - this is enabled
on some Linux distributions, and disabled on others.
In order to enable it, you need to edit /etc/X11/xorg.conf and add the following to the
Second, certain Linux distributions (Ubuntu) display GameMode as a quarter-screen display.
I've added a hack to glutGameModeString that corrects this.
Third, glutFullScreen only works correctly on Linux via KDE - all other X11 window managers
display window borders/decorations.
Fourth, glutReshapeWindow (when called after glutFullScreen) does nothing on Gnome;
works fine on KDE, produces undefined behavior on other X11 window managers.
Finally, glutPositionWindow (when called after glutFullScreen) doesn't seem to work
correctly on any Linux/X11 window manager.
After scratching my head all day on the glutReshapeWindow/glutPositionWindow issue, and
getting ready to bail on it - I stumbled across glutPostRedisplay... and voila, they both
now work on all X11 window managers. I've encorporated this in glpRestoreScreen, so now
it works correctly after a glpFullScreen.
I've checked this into SVN.
That said, if you want to get rid of the borders/decorations on Linux - use KDE's window manager.
Also - finally cleaned up all the implicit-cast build warnings in the code.
April 30, 2008
I've added glutCloseFunc and glutLeaveMainLoop.
The FreeGLUT implementation of glutCloseFunc doesn't return a window ID, so
you don't know which window is closing. I've added a window ID to POGL's
For glutLeaveMainLoop, I'm calling glutDestroyWindow, if FreeGLUT is not found.
glutReshapeWindow (and therefore glpRestoreScreen) doesn't seem to work correctly
on Ubuntu (I may have and old verison of FreeGLUT). Also game mode is a bit
freaky on Ubuntu. Will have to check it out on Fedora.
Other than that, glutCloseFunc seems to work well on Windows and Linux. I've
checked in my current release into SVN.
I think I've worked out how I'm going to port FreeGLUT to Parrot/NCI.
April 29, 2008
The problem with GLUT Game Mode is that you use it instead of glutCreateWindow - making it
a pain to switch back and forth between full screen and windowed displays...
so I added glpFullScreen and glpRestoreScreen which can be used to dynamically switch
between full screen and windowed under glutCreateWindow:
Note: certain X11 window managers do not handle full screen correctly - the system menubar
$Window_State = glpFullScreen();
April 28, 2008
I've added POGL build options to select GLUT or FreeGLUT, with the default being FreeGLUT.
This adds the ability to catch window close events, via
On Windows, installing POGL now automatically installs FreeGLUT.
I also added build options for creating binary distributions of POGL - currently only useful
on Windows, since WGL supports dynamic loading/discovery of OpenGL extensions.
I'll check this into SVN later in the week, after I've had a chance to add some other
features I've been trying to get into the next release.
April 24, 2008
Just received a screenshot from Dr. Mitchell Laks of Montefiore Medical Center.
He used POGL to create a DICOM CT/MRI Scan Viewer Worstation.
I've featured this in POGL's current Spotlight.
He just gave a talk on using open source Perl for building CT Workstations
at last week's American Roentgen Ray Society meeting in Washington, DC.
I just have to quote his email to me:
Thanks to POGL it is MAGICALLY VERY FAST!!!!!!!!!!
Mitchell - you are amazing for getting this to work - thanks for
demonstrating yet another use of POGL!
YOU ARE AMAZING!!!
April 19, 2008
Received a patch from Alex Dodge last November to add support for glutKeyboardUp;
finally got a chance to add it. While I was at it, also added glutSpecialUp and
glutWindowStatus. Note: requires GLUT 4.0
Also fixed a couple of build warnings.
April 16, 2008
Since taking over POGL, I've mainly focused on adding support for new OpenGL extensions;
I haven't used any of the GLU APIs. Fredrick Wagner reported issues with
gluUnProject_p - I perused the code, and found bugs in the original OpenGL port.
Both gluProject_p and gluUnProject_p were truncating doubles to ints, causing significant
rounding errors, and frequently causing the APIs to fail.
I've fixed these and have checked them into SVN; they will be in the next release.
While I was at it, I also added an example of glutMouseFunc in test.pl
I also updated documentation for
adding an example for using C pointers, and added documentation for the new
calc and affine methods.
Now that I have some spare time, I hope to get 0.57 out shortly, then focus on:
Adding Geometry Shader support
Adding video support (input and output)
Switch from GLUT to either FreeGLUT or OpenGLUT
Make POGL object-oriented
Port to Parrot
April 9, 2008
I received a gallery submission from Fredric Wagner,
Assistant professor ENSIMAG - INPG,
Laboratoire d'Informatique de Grenoble - MOAIS team.
He's using POGL to trace execution of parallel computations.
I also received a gallery submission from Krystian Samp,
Digital Enterprise Research Institute - HCI Lab.
He's using POGL to visualize large amounts of data in 3D space, via filters
Two in one day!
April 7, 2008
I was made Open Directory Project (dmoz.org) editor for:
Good fit for POGL.
April 1, 2008
I've resigned from Appscio, in part to spend more time on my own projects - like POGL.
They have a good vision and team; they recently hired the original GStreamer author.
- I wish them the best!
March 26, 2008
I've been discussing with members of the Perl6 community the possibility
of porting POGL to Parrot. Parrot is a language-independent VM adopted by Perl6 and
other languages to support compiled modules.
The main sticking point is that GLUT's callbacks are not thread-safe, and cannot be
supported by Parrot's NCI interface. In order to do this port, I will need to
make POGL object-oriented (something I've been wanting to do since I've taken over this project),
and then build a wrapper around GLUT's callbacks.
Unfortunately, there is no way that I can pursue this while I'm in full-time employment.
March 5, 2008
POGL currently supports 5.6 and 5.8 PPMs; received a request from Shane Calimlim
to make a 5.10 PPM available. After an initial test, POGL builds fine as a 5.10
PPM - however, ImageMagick (used by OpenGL::Image) is barfing.
Need to investigate this further.
February 5, 2008
Received word from Mitchell Laks that he has succeeded in using PDL and POGL
to render CT and MRI scans. Quote: "POGL is nice and fast".
December 29, 2007
I just received a 2007 Mozzies award from the Open Directory Project (dmoz.org),
which is used by major search engines (Google/Yahoo/MSN) as part of their ranking
I'm the ODP editor for a number of Perl and openGL sections.
December 13, 2007
Jan Dvorak, a primary contributor for RubyGL, has ported Geoff Broadwell's Trislam benchmarks to
Ruby, and found that the Ruby OpenGL binding is about 2-3X slower than POGL.
I will post his benchmarks when I get the chance.
December 9, 2007
POGL has always run under Cygwin via XTerm - however, I had never tried to build
it under Cygwin.
Received a patch from Chris Marshall back in September that adds support for building
POGL under Cygwin; I finally folded it into the code base - it's checked into SVN and
will be available in the next release.
November 10, 2007
Finally decided to give up on GPGPU support for OGA's Affine routine for now.
This is checked into SVN. I'll hold off on doing a tarball/zip until I've completed
a few more patches/fixes.
I also decided to rename my new OGA Update/Process routine to Calc. Update was
misleading, as the routine can be used to initialize OGAs, and Process would conflict
with an OpenGL::Image subclass I was considering. I had thought about naming it
RPN, to allow for other possible interpretters in the future... but decided to just
stick with Calc. I'll document shortly.
November 3, 2007
Finally got around to fixing my benchmark/build machine. Good news, it now multi-boots
When I originally built this machine, I made the mistake of installing Vista first -
preventing the installation of XP afterwards - making it impossible to benchmark the
two on the same machine. Now I'll be able to compare performance between XP and Vista.
I also took the opportunity to upgrade from Ubuntu Dapper to Gutsy. Note: Gutsy
has it's own Debian nvidia driver (which does not install libGL) -
and makes it difficult to install nvidia's driver (which does install libGL).
I'll need to add a README to explain how to install nvidia's OpneGL driver under
Gutsy - as neither nvidia's nor Ubunru's sites do.
October 31, 2007
Apparently Antti Lankila had started a non-CPAN 0.54 branch last year and managed to add 4
extensions - but has since ceased maintenance. Since 0.55 included support for over 50
new extensions (including Antti's 4), the Debian Perl Package folks have
now decided to switch to POGL's current CPAN branch.
Their main concern is my inclusion of GL and GLUT header files, and creating binary dists
that are not tied to specific header files. Unfortunately, the only way to get around
this on non-Windows systems is to use Mesa - which does not support all of POGLs latest
extensinos. For now, they will manually remove these header files, and tweak the makefile.
I'm considering removing the header files for future releases, and making them available
as separate tarball/zip files.
October 28, 2007
Just noticed that there's a Debian binary package for Perl OpenGL - branched off of 0.54 -
contacted Debian's Perl package maintainers to see if they might be able to update their
October 27, 2007
October 4, 2007
I've rewritten the GPGPU version of OGA's Affine transform several times, including
caching shader programs and FBOs. The performance has improved somewhat, but still
unacceptably slower than the CPU version. The primary bottleneck is in binding the FBO.
Following my most recent rewrite, I've managed to get the GPGPU version to only 10X slower
than the CPU version - if the arrays are very large, and the affine transform is
repeated 100 or more times.
May be able to explore ways to render to a VBO that might be faster. May
eventually try this out with CUDA (unfortunately, nvidia-only). Going to take a
break on this for a bit.
October 1, 2007
Started my new job as CTO of Appscio.
September 29, 2007
Doing some benchmarks on my new OGA Affine function, and found that the GPGPU version is
about 2000X slower than the CPU version. The results are correct - just inexplicably
Contacted by a Google recruiter for a senior role. Interested, but informed them that I'd
already accepted a position at Appscio.
September 25, 2007
I had originally planned to add two new OGA/RPN APIs: Update and Combine - the first
for initializing and updating OGAs, the second for combining two or more OGAs.
Turns out that a single API can do both. Assuming a 3xN OGA:
$oga->process(0,'5,+','2,*') - sets the first column to 0, adds 5 to the second column,
and multiplies the third column by 2.
$oga0->process($oga1,$oga2,'sum','avg','+,*') - sets the first column of oga0 to the sum of
oga0, oga1 and oga2, then sets the second column to the average of the three OGAs, and
then sets the third column to the third columns of (oga0 + oga1) * oga2.
This allows you to quickly initialize large VBOs, modify columns per pass, and even
combine OGAs for complex particle physics.
My current implementation is CPU-based, but the RPN engine could be ported to GLSL,
abstracting/simplifying VBO handling for cards that do not support shaders, and allowing
developers the benefits of particle physics without needed to learn GPGPU/FBO/VBO/shader
The only part of the RPN engine that I won't be able to port to GLSL is the Rand function -
but I may be able to simulate it.
I haven't had a chance to benchmark this yet (need to jump on the Cygwin and gluTess stuff first),
but I've thrown together a fountain demo using 3 OGAs and a line of RPN code to handle
all the particle physics. Seems to be fairly fast.
I'll post this after I get the Cygwin and gluTess changes folded in.
September 22, 2007
Just received an email from GŁnter Bachelier - seems that switching from PerlMagick
to using POGL for his tiling engine has worked out well for him. He uses this for
generating large digital artwork.
September 21, 2007
Earlier in the week, I had decided to add support in oga->update for 'stacked' operations -
in other words: '*rand(1.0)+sin(pi)'.
Having started down this path, it really felt wrong to create a new, half-assed, c intepretter
for this purpose, nor did I want to load a Perl interpretter for this purpose
(OGA is written in C/XS).
So today I created a forth-like RPN (Reverse Polish Notation) engine, and rewrote oga->update
to support this. Turns out that this really simplified and cleaned up the code, and
makes the engine far more extensible for furture features.
RPN is a postfix, stack-based engine - you push your data onto a stack then execute your op.
Example: 'pi,sin,2.0,*' is the RPN equivalent to the following C: '2.0*sin(pi)'. While it
may not be as readible, it's much easier/faster to parse and executes quickly.
Here are the ops I'm supporting so far:
push a value/constant
push a random value
push a duplicate of the last item on the stack
swap the last two items on the stack
add (decided no need for sub)
div - NOP for divide by 0 conditions
I'm contemplating whether to add conditionals, ability to reference other array elements by index,
and adding data registers.
Your feedback/input on this would be appreciated.
September 19, 2007
Since SIGGRAPH, I've been approached by several startups doing GPU-based work -
to join their teams. After meeting with a number of their VC/investors and
board members, I've decided to join one of them as CTO: Appscio.
Appscio provides pipeline frameworks for "Actionable Video Intelligence" - in other words,
a plugin architecture for video/audio/event analytics.
I'll continue to own Graphcomp and maintain/enhance POGL - just switching my day job.
Opensource is a big part of Appscio's work, so we may actually be able to leverage
POGL's portable GPGPU interfaces.
September 14, 2007
I added the following OGA APIs for vector transforms:
Assuming a 3xN array, this sets the first column to 1.25, leaves the second
column alone, and sets the third column to a new random value between
0.0-1.0 for each row. You can prefix parameters with '+' or '*' to modify
existing values (eg: '*2.0').
This should simplify the initialization and modification of VBOs; I hope to post
September 13, 2007
I've been having some discussions with Geoff Broadwell on adding support for GPGPU processing of
vertex arrays/objects. I've decided to add new OGA APIs to support affine and scalar
Received reports from a couple fo developers that they are having problems using the
Also received a message from Chris Marshall (maintains PDL::Graphics) regarding issues
building POGL under Cygwin; he's sent some patches, which I hope to integrate shortly.
He also voiced an interest in becoming a POGL contributor to help integrate POGL
with PDL's data transforms and improve POGL's glpWindow portability.
I Will follow up on both of these tasks as soon as I'm finished with my new OGA APIs.
September 11, 2007
Released the following POGL update:
Updated test.pl to fix fullscreen handling
Fixed OpenGL.pod to reflect correct module name
Added FBO constants to param enums in gl_util.c
September 4, 2007
Released OpenGL-Shader v1.01 with the following changes:
Removed duplicate documentation in Shader.pm
Added support for parameters fewer than 4 in SetVector
Updated GetTypes and HasType to reflect changes in OpenGL::Image
Updated OpenGL-Shader.t to reflect changes
Fixed tests for shader support
Added Geoff's shader-test.pl
September 3, 2007
Posted in our Gallery a snapshot and video of Geoff Broadwell's sample fragment
shader; his script will be included in the next release of OpenGL-Shader.
September 1, 2007
At the request/urging of Geoff Broadwell, I've added support for the
GL_ARB_point_parameters extension. While I was at it, I also added
GL_ARB_multisample and GL_ARB_color_buffer_float.
This morning, I updated OpenGL-Shader to reflect Geoff's API changes in
OpenGL-Image, added a shader test app that Geoff wrote, and made SetVector
a bit more flexible.
I'll be posting these updates shortly.
Next big project: OpenGL::Video
August 30, 2007
Released OpenGL-Image v1.02 with the following changes:
Removed redundant documentation from Image.pm
Fixed/enhanced priority handling and engine info retrieval
for GetEngines and HasEngine.
Cleaned up NewEngine.
Cleaned up Image.pod, INSTALL and README.
Fixed version number for OpenGL::Image::Common
Updated OpenGL-Image.t to reflect Geoff's changes
Much thanks to Geoff for the fixes/enhancements, and excellent
recommendations regarding module direction!
Received some excellent feedback from GŁnter Bachelier regarding the latest
tiling script. He's listed POGL as a
August 27, 2007
Put together a new tiling script: p3m.pl,
based on hex_tile.pl (comes with OpenGL::Image) that renders to an FBO,
then resamples the FBO for additional processing prior to rendering to the screen.
Note: requires POGL 0.57_1 - which I will post in a few days.
Did this primarily as an exercise to demonstrate offscreen tile generation, for
use with dynamically-generated tiles for texture/bump/normal maps.
Just posted new videos in the Gallery.
August 24, 2007
Created a new tiling script for GŁnter Bachelier, which renders tiles to a framebuffer,
then further processes the tiles prior to final rendering to screen or file.
In the process, I uncovered/fixed an OpenGL module bug in
- will add it to the next POGL release.
August 23, 2007
Received some patches from Geoff Broadwell just prior to SIGGRAPH
to fix/improve GetEngines/HasEngines handling...
finally got around to folding them in; I'll post the release shortly.
Geoff did a great job in cleaning up the code and documentation - thanks, Geoff!
August 20, 2007
Released an updated OpenGL::Image module with the following changes:
Fixed typo in test app
Added support for 24 bit images in Targa.pm
Added support for runlength-encoded images in Targa.pm
Fixed non-alpha image handling (eg: JPEGs) for unix in Magick.pm
Updated STDERR handling when attempting to load image modules
Updated SyncOGA in Magick.pm to handle image resizing.
Added hex_tile.pl screensaver
August 18, 2007
Wrapped up some contracting after my return from SIGGRAPH - then went back to
my tiling work...
Figured out why my tiling demo wasn't working on Linux - PerlMagick handles matte/alpha-channels
for JPEGs differently on Windows and Unix. Had to update OpenGL::Image::Magick to
compensate for these differences. Will post a new release shortly.
While I was at it, decided to add support for 24 bit and runlength-encoded images
Posted a new tiling snapshot on the gallery Spotlight - looks pretty cool.
I have some ideas on some interesting texture/bump/normal maps based on this.
Updated the POGL screensaver I wrote while at SIGGRAPH; will post this shortly.
Skip SIGGRAPH reporting.
August 10, 2007
This year exhibited ongoing progress in the areas of cloth, hair and water simulation, and new progress
in simulating bubbles and foam.
Face and skin rendering is nearly perfect, as is motion capture/rendering. 3D capture of form and
texture is improving - still has a ways to go. All the tools are coming together for the CG grail
of realistic people rendering.
Geometry Shaders (via Direct3D 10 and OpenGL GL_EXT_geometry_shader) have provided an incredible
advance to the GPU pipeline, dramatically reducing the amount of initial data that needs to be created
and loaded on the GPU, and providing far more flexibility and speed in procedural rendering -
particularly in the areas of particle-based rendering and hair.
nVIDIA and ATI have created new GPGPU interfaces to simplify load-balancing code between CPU and GPU -
however, until a vendor-independent standard is established, most application developers are likely to continue
using traditional GPU interfaces such FBOs, VBOs and shaders to balance operations between CPU and GPU.
3D ubiquity (web, PCs, hand-helds) is attempting a resurgence from the VRML days of the mid-90's. X3D has
replaced VRML 2 as a cross-discipline interchange/distribution format for 3D models. A few X3D
plug-ins are becoming available - the requirement to install a somewhat large plug-in is still
somewhat a barrier for wide adoption. PaperVision3D has developed some interesting 3D rendering
capabilities within Flash. While Flash is clearly a very hefty plug-in - it has been widely adopted
by a younger demographic - providing a good audience for certain types of use. A PaperVision3D
implementation of an X3D viewer would be very interesting to see.
Hardware, bandwidth, photo-realistic content development tools designed for art professionals - have
all come together to make the timing right for immersive interfaces to replace traditional
2D presentation/navigation of information/entertainment. This next year should present some
exciting changes to the industry.
August 9, 2007
Full-day course on modeling, animating and rendering hair.
Elliptical cross-sections with helical coiling introducing clumping and other interactions
Hair bends non-linearly, and introduces twisting
Hair is made up of scales, intoducing friction and optical effects
Translucency, plus natural and cosmetic films, affect visual appearance
Implantation affect direction/grain fo hair
Hair cut, balding, artificial coloring, partings, braids, pins and other coif'g affect rendering
Guide hairs minimize the number of individual hairs that need to be modeled. Interpolation
near the roots provide naturally-appearing distributions.
Waves/curls can be modeled over cylindrical deformations or procedurally rendered based on distance from root.
Bubbling and Frothing Liquids
Determining origin location, distribution anf frequency
Bubbles expand and join, which affect bouyancy and motion
Bubbles interact with each orther, surrounding fluid and surface materials
Drag is impacted by fluid and bubble/foam density
Bubble resistance to joining, and cohesion tendencies
Bubble bursting factors
Need to preserve fluid volumes and handle compressable gas volumes
Shape changes based on velocity, viscocity, pressure and collision
Presenter demonstrated excellent simulations of various carbonated beverages being poured into mugs.
First half hour of the meeting was dedicated to the process of submitting papers, and a slide
showing the low rate of people returning to participate in this group (Applied Perception and Graphics).
Several people left before the presenters got around to explaining to the audience what the goals of
the group are; they never explained the purpose of this meeting, nor did they get around to actually
talking about Perception and Graphics.
The remainder of the session was spent discussing the group's name:
The word "Applied" apparently scares off psycology researchers
Others dislike the use of "Graphics", "Computing" or anything else having to do with real-world applications
Some questioned the cost (loss of "brand") of changing the group's name
Quite a few people left after the name change discussion began.
Misleading session title. I suspect that many in the audience (like me) simply stayed for the
following session: X3D.
Web 3D Working Group
Discussions on the status and direction of X3D
X3D is essentially VRML 3 - with one major improvement over VRML 2.x - the establishment of
compliancy specifications, including the minimal requirement of a behavioral scripting language: ECMAScript
Most of the 3D standards that are currently emerging are focused on game development. X3D promises to
be a real cross-discipline interchange specification for gaming, CAD, GIS, volumetric medical imaging,
The X3D-Earth project will provide a scalable opensource project for collaboratively storing/adapting/sharing
geo-positional data - for factual (research/encyclopedic) or fictional (gaming/story) use.
Accepting papers/presentations for November's X3D conference in Sao Palo, Brazil.
August 8, 2007
Volumetric pixels (voxels) were widely used by military flight simulators back in the early 80's; vertex
buffers have made it easy to render to voxels and use this for various purposes - such as fast (but low-res)
collision-detection, velocity/physics and gathering events (paint splatters).
Achieve sharp edges despite close-in zooming
Avoid thresholding (aliased stairstepping)
Avoid interpolation (blurred edges)
Avoid expensive in/out side calculations
Fast - minimal operations and code
Portable to many GPUs
Solution: store outside edge distance in the alpha channel
Fast, clean, cheap
Alpha channel can be reused for boundary glow and drop shadows
Hogel colors are viewer-normal dependent. Presenter used OpenSceneGraph to associate metadata
(such as viewer normals) over standard OpenGL elements - while remaining hardware independent.
It's unclear to me why in this day and age one wouldn't simply use hardware that supports vertex shaders.
Fluorescent Blue overpowers all other colors - which can be somewhat ameliorated by reducing print dot size
and using well-conditioned half-tone patterns.
Applications might be night-light presentations/art, tagging/signing documents/money, and enhanced hybrid printing
systems. Examples presented under UV light reasonably approximated original images.
Limits of human vision (resolution, hue/brightness)
Shape, material recognition, reflection/refraction/opacity/lighting
Test Illumination Transformations;
Blur - material roughtness
Warp - bumpiness
Shape complexity and surface roughness reduce impact of illumination transforms.
Based on human test, presenters developed a predictive model of visual equivalence.
Warp metrics can be applied to light-cutting - where a single large light replaces a cluster of smaller lights.
Warp metrics can also be applied to radix-mapping for optimized bump-mapping.
Shape influences specular reflection and how we perceive materials. Changing material will result in
a 16% chance of perceived change in a target shape. Changing a shape is equivalent to a 12% change
in perception of material.
Tesselated (faceted) objects are poor targets for percieved changes in material. Blobs have the lowest
threshold for recognizing material change; spheres have the highest threshold - therefore, blobs
provide a better generic shape for testing materials.
August 7, 2007
GPUs are not just about graphics - they are processors tuned for optimized processing of
large arrays/matrices of data.
CPUs have scaled up to 2 and 4 cores; GPUs currently have more than a hundred cores, and are scalable
to thousands of cores.
GPUs are much faster than desktop CPUs and are much less expensive - as such, it makes sense to
use GPUs for parallel data processing.
GPU performance is improving 2-3X per year.
+$500M GPUs shipped per year; GPGPU uses:
GPGPU processing involves 3 programmable stages (shaders) in it's pipeline, each of which are highly parallel:
Vertex program - processes arrays of 4 element float data input.
Geometry program - emits/culls primitives - essentially parallel branching.
Fragment program - combines parallel output from above stages for output.
NVidia's CUDA and ATI's CTM provides a GPU-specific interface to GPUs, bypassing graphics-centric interfaces.
: if your GPU is already doing graphics-intensive processing, doesn't GPGPU "rob Peter to pay Paul"?
: given a choice of doing the parallel processing on CPU, or time-slicing on the GPU, the GPU is better
suited (more efficient) for doing this processing. It's also generally easier/cheaper to install an additional GPU
than it is to add another CPU.
Common GPGPU operations:
Map - fragment shader applies a program across a set of data
Gather - fragment/vertex shader can read from global memory (texture)
Scatter - fragment shader can write to global memory (frame buffer and inter-thread data sharing)
Scan - fragment/vertex shader can stream compress data
Choose algorithms with good data locality - use the same comparison for all local data elements.
Push work to the vertex program over the fragment program.
Use GPU blending operations for compare.
Map 1D arrays to 2D arrays for optimal GPU use.
Bitonic merge sorts are over twice as fast on GPUs than generation-comparable CPUs.
External Memory Sorting maps to GPUs well, by partitioning runs into parallel chunks.
Hybrid CPU/GPU sorting provides the best performance per dollar over all CPU-only solutions for
terabyte sorting - as measured by Indy SortBench benchmarks.
The Job Fair, sponsored by CreativeHeads, opened up today in Hall D.
You will need to use your swipe card (from your ID packet) in order to access the Job Fair. There
are a number of workstations set up by CreativeHeads for updating your resume and appying for jobs.
Representatives from various digital arts companies are represented, with private booths for
on-the-spot interviews - if your experience matches their immediate needs.
For artist positions, you should have your demo-disks/portfolios available. For engineering positions,
they seem to be expecting printing resumes. I did not see printers in the area, so bring your printed
resumes with you.
The normal exhibitor fair. I'm not here to review products - I'll leave that for the other blogs.
There are food vendors (over-priced) at the back of the exhibition halls - if you don't have time for the pavillion
upstairs, or the local restaurants outside.
As always, the SIGGRAPH Electronic Theater was fastastic, in every sense of the word.
The pre-show presentation included music/video compositions, interspersed with diffused laser projections.
The show started off with a tribute to early vector pioneers, using a vector laser presentation of early arcade games,
where members of the audience were invited to play Asteroids, Tempest and Star Wars on the big screen.
This was followed by a brief intro, where vector laser renderings were overlaid (with perfect registration)
over a video projection - quite a technical feat.
ALL the presentations were inspired, technically impressive and creatively challenging. Of special
note for me (from the Tuesday Matinee)...
- Scrat continues to be a Pixar favorite, this time in a time-travelling short.
- a beautiful and emotional rendention of partners in a Tango of memories.
- socially crude, but well-rendered and FUNNY. Men at their best/worst.
- You've seen this U2 / Green Day music video - still moving.
- short - simply brilliant.
- you have to be a geek to appreciate this one - hilarious.
- THE MOST AWESOME 1ST PERSON SHOOTER WEAPON!
Salsa Dancing at the Adobe/Maxon party.
Adobe and Maxon co-hosted a party to celebrate/promote their "Power Integration Tour", using Adobe's CS3 and
Maxon's Cinema 4D previz products for collaborative film making.
A buffet/bar was provided, live music, dancing, and several goodies were raffled off: nVidia cards,
CS3 and Cinema 4D.
It was a good way to unwind, and to share ideas for collaborative projects.
August 6, 2007
Note: if you arrive early at the Convention Center, you can enter in through the doors
at Hall C. It's nice and peaceful here before the crowds arrive - and wireless access is great.
The first showing of the Electronic Theater will be this evening at the San Diego Civic Theatre, 7PM.
You should have already signed up for a showing; your ticket is in your ID packet.
Shuttles to the Electronic Theater are free, and will be outside Hall B. Depending on traffic, it
may take 20+ minutes to get there, and you'll want to be there early, so plan accordingly.
Alternately, you can briskly walk there in about 20+ minutes. Go left (NW) from the Convention Center up
West Harbor Drive, turn right (N) on 1st Avenue, past C Street, right (E) on Broadway, left (N) on 3rd Avenue -
it's about a block up on your left.
I will be reviewing the Electronic Theater on Tuesday, during the 2:00 matinee showing.
Well that was disappointing... we had a reasonably full audience for the AJAX 3D BOF - but the speakers/organizers
failed to show up, or notify us that the session was cancelled.
A summary of things that we discussed amongst ourselves:
ajax3d.org leverages an X3D plugin
papervision3d.org provides 3D affine transforms and shaders via Flash ActionScript
server-side pre-rendering for low-parallax objects (panoramas)
memory conservation by leveraging browser DOM objects
We also discussed the obstacles to immersive browsing:
VRML 1.0 was successful in that it a) provided the first reasonably comprehensive, portable 3D model standard and
b) was open and player/plugin development was reasonably simple.
VRML 2.x killed VRML innovation by adding complexity and failing to standardize behavior scripting.
3D/immersive content creation continues to be roadblock. The industry needs tools to allow
graphic artists and videographers to easily generate content without having to be CAD engineers.
Broadband, hardware and user awareness has made immersive interfaces feasible - however, we
still lack browser side support (eg: AJAX) - unless we force users to download a player-plugin (X3D, Flash, etc).
Gaming, multi-user communications
Immersive UI vs 2D desktop navigation
Minimize solid-body oscillations by:
calculating volume and form divergence separately
calc friction separately, after pressure calcs
Using parallel computation and commong web search techniques for user-controlled multi-body motion:
Searching/sorting by velocity, duration, collisions, etc
Interactive user criteria and queues
Order of magnitude performance improvement for articulated object collisions by
detecting time of first collision through:
estimated trajectories using linearly interpolated motion
elimination of objects/parts farthest from target objects in time/space
Elastic: temporary deformations; eventual restoration of shape
Plastic: permanent deformations
viscoplastic: semi-plastic deformations
Traditional approaches involve subtracting a portion of the elastric restorarion from the target rest state.
Presenter described using yield stress, flow rate and hardening/softning work load to weight elastic and plastic
deformation matrices. Shapes must be remeshed at intervals to ensure well-conditioned meshes. Remeshing
also allows for tearing and reconstitution of shapes.
Note: culling during remeshing causes loss of volume/mass
over time - need to provide volume compensation.
Today's lunch accompanied by the light percussive sounds of Jamaica.
August 5, 2007
Weather: warm, cloudy, overcast, muggy.
Wireless: speed is good, however I've found a few spots in various session rooms where
I loose connectivity every few minutes or so - wireless is fine out in the corridors and patios.
Attending the full-day course on DirectX 10. Yeh - POGL is about portable OpenGL, but we all
need to know what else is happening around us, right?
Review of Direct X History
DirectX 9 is now core to Win32 and replaces GDI
D3D 10 now only supports HLSL (no low-level assembly)
No (default) null-vertex/pixel shaders; there continues to be a null-geometry shader
Same instructions sets for vertex/pixel shaders
All APIs prefixed to reflect pipeline stage
D3D 10 allows you to determine what is done on the CPU vs GPU for load balancing
Review of Geometry Shaders
Note: Geometry Shaders are supported via OpenGL's extension on DirectX 10 compliant cards.
Vertex shaders allow you to modify vertex attributes (position, normals, texcoords, etc); fragment/pixel
shaders allow your to modify interpolated pixel attributes (color, depth).
Geometry shaders operate on surface/line primitives, allowing you to modify, introduce/emit, and cull geometry before
it goes to the fragment/pixel shader.
Geometry shaders even allow you to create your own fragment interpolator to pass to the Pixel Shader pipeline.
This allows you to use non-linear interpolators for improved rendering. You can emit to multiple array
indexices - eg: separate faces of a cubemap.
The Stream Out stage following the Geometry shader allows you to output to a buffer that is not
part of the rendering pipeline.
You can now index 2D arrays (textures), for both reading and writing/rendering. This simplifies
layering, combining or switching between textures
Resource views are typeless resources that are validated at init time, allowing hardware to optimize pipelining,
while providing more flexibility and ease of use for developers/drivers.
For example, a mipmapped cubemap could be represented as 6 indexed render surfaces, which can be selected as a
render target, then later as an environment map.
D3D 10 makes it easier to use arrays of textures - howver, it also increases the likelihood of
fragmenting memory and crashing your app. You need to re-use resources as much as possible.
Resources are tightly bound to specific instances; it becomes more critical to keep ref-counts in sync.
Demos show that per-pixel lighting increases dynamic range, better detail and improved shadows.
Presenter recommended using instancing over geometry shaders when possible.
Presenter described using D3D 10 for rendering to multiple windows/contexts and multiple monitors with
a single card, and explained the process of enumerating adaptors and outputs for rendering various
views of the same model space.
Resource Views are bound to swap chains, textures and stencils, which are bound to render targets -
which are tied to specific windows.
Lucas Arts pesentation talked about how developers will always pack more features into a rendering pipeline
to keep production at 45 minutes/frame - yet designers continue to drive performance towards real-time.
This is achievable by partitioning content processing, front-loading tasks that can be pre-rendered, and
instrumenting pinpoint bottlenecks that can be tuned or eliminated.
Presenter discussed a modular process that is a hybrid between Ad Hoc and Structured processing to
minimize loops over process bottlenecks.
Wanted to show that SIGGRAPH wasn't just about dark presentation rooms ;^)
The Convention Center has a rather small food court, in the upstairs pavillion, next to Ballroom 6 and Ballroom 20.
There's a nice patio just outside the pavillion, with a beautiful view; there's a live taiko drum performance
going on during the lunch break.
Note: the food court is cash-only - so have cash handy.
There's Starbucks booths throughout
the Convention Center. If you have
time, there are also many fine restaurants/cafes surrounding the Convention Center.
The gallery is upstairs in Ballroom 20.
August 4, 2007
Just arrived at the San Diego Conference Center - early registration.
Weather: warm, sunny but hazy.
Clothing recommendation: I'm here in shorts + t-shirt, and I'm burning up
(I used to live in Southern California) - so dress lightly.
You might want to bring layers, in case they eventually crank up the AC.
As usual, SIGGRAPH hides the registration center at the most remote section of the conference...
when you arrive, go the farthest end of the Center to Hall H, first floor.
If you've pre-registered, don't forget to bring your printed confirmation sheet (w/ barcode), and a photo ID.
Badge pick-up is streamlined and quick; in-and-out in a few minutes.
I stopped by the Media Press Center to see what it takes to qualify for a press badge...
seems that a personal blog doesn't cut it ;^)
Open wireless is available (SSID 's2007'); it was quite fast when I first got here...
slowing down as more people arrive, but still fairly good. Note: you'll need to open up a web browser to establish a session,
before you can use email, ssh, etc. Past SIGGRAPH conferences have had wired access, as well - I guess they've
abandoned this old-school modality - haven't found any available ports
(other than those used by vendors).
The conference has provided free shuttles to off-site sessions (eg: UCSD, Civic Center).
The shuttle stop for the Electronic Theatre is just outside Hall B.
For shuttles to hotels (after session parties, etc), you'll need a shuttle wristband;
the hotel shuttles are located just outside Hall F. If you are registered
at one of the official SIGGRAPH hotels, the hotel will provide you with a wristband. Otherwise, you'll need
to buy a wristband at the SIGGRAPH Store (between Hall F and G) US$75 - the line is slow...
To repeat - you don't need a wristband to go to an offsite session - just to get to/from the hotels.
No wireless access on the shuttle; I'm posting this blog entry while riding the shuttle to UCSD - connected
via EDGE/GPRS on my cell phone.
Note: the shuttle ride to UCSD took over 30 minutes, not counting a 15 minute wait for departure.
If you arrive late to a performance, you are SOL - they
only let you into the theatre during intermissions - so plan your schedule accordingly.
Note: the Electronic Theater (what we all came here to see) is offsite at the San Diego Civic Theatre -
it's a 20 minute shuttle ride;
you'll want to be there early for the best seating. Remember to bring your Electronic Theater ticket
(it's in your ID pass packet).
Wireless access is available at UCSD if you are a student there - otherwise you'll have to wait until you
return to the Convention Center.
The UCSD California Institute for Telecommunications and Information Technology (Calit2)
Has a 4K (8 mega-pixel) theatre - worth checking out.
This is a presentation on capturing Leonardo's
"Adoration of the Magi" in multi-spectral frequencies (x-ray, UV, IR, visible) in order to separate various
underpainting layers - allowing researchers to unravel the artist's creative process.
The presentation title refers to a distance sensor which uncovered layers of imaging
as the presenter approached the projection screen - revealing underlying charcoal sketches by Leonado,
never before seen by the public.
Other presentations included live performances involving interactive digital media and motion/audio capture.
August 3, 2007
Was contacted by German artist/mathematician GŁnter Bachelier a few weeks ago,
asking about using POGL for generating hexagonal tiles from photographs.
He had been doing this using ImageMagick, and found it to be quite slow to
do all the transformations manually.
I finally found a few free moments before leaving for SIGGRAPH to bang out a
simple POGL script that uses tri-strips and simple texcoords to dynamically render
animated tiles. Very psychodelic!
You can see some snapshots on our Gallery.
I'll post the code to generate this after SIGGRAPH.
July 30, 2007
I spotted the following, posted on PerlMonks in reply to my POGL 0.56 and OpenGL-Shader posting
- attaboy's much appreciated! :)
BTW - if you register on
(an opensource tracker), you can add my projects to your "stack":
This is great news, actually. I've been following the
improvements on this module since you've taken it over
from the previous maintainer, it has seen tremendous
improvements. All I can say is just keep up the good work!
I have used 0.55 for my personal project, but I have to say
with 0.56 and GLSL, things will be much easier for my code.
July 29, 2007
Released POGL 0.56, which adds support for GLSL and Cg shading languages.
Released OpenGL::Shader, which abstracts APIs for ARB (assembly), Cg and GSLS
Note: I'll be reporting from SIGGRAPH on this blog next month. Stay tuned!
July 6, 2007
The ImageMagick team just released 6.3.5 with my new PerlMagick APIs.
In parallel, I've released OpenGL::Image 1.00 which leverages those
APIs to provide tight integration between POGL and imageMagick.
July 4, 2007
Added POGL support for the following OpenGL extensions:
Implented a new extensible OpenGL::Shader module to abstract loading/managing
OpenGL shaders. Testing; should release soon.
July 2, 2007
Received confirmations from Mac developers that OpenGL::Image is working for them.
I'm ready to release, as soon ImageMagick is ready to release 6.3.5
July 1, 2007
Contacted Allen Day, author of the FFmpeg Perl module. Discussed adding APIs to
support tight integration with POGL, similar to those I added to PerlMagick.
His module is dependent on a very old version of FFmpeg, and depends on a number of
other libs not needed by POGL; I'm debating whether to
update his module to the current FFmpeg release, or just doing my own FFmpeg
June 29, 2007
I've posted a new OpenGL::Image Targa driver - this loads/saves uncompressed RGBA images.
I added this for use as a prototype to create other imaging engine drivers,
and to support developers that prefer not to install ImageMagick.
Fixed GetPixel/SetPixel in OpenGL::Image, and changed the default engine from
'Magick' to 'Targa'.
You'll need to update to POGL 0.55_04 for the new test.pl file.
June 28, 2007
I've released a new OpenGL::Image module that leverages the new APIs I added
to PerlMagick (6.3.5). It abstracts image load/modify/save operations, and
allows the GPU to share image buffers with ImageMagick via C pointers.
Simulatenously, I've posted a new POGL 0.55_03 release that fixes a
glBindBufferARB build dependency, and adds a number of APIs that further
improve imaging performance.
You can now:
Load Textures, FBOs and VBOs via PerlMagick
Bind ImageMagick's image cache via C pointer to your display frame or an FBO
Modify FBO contents using PerlMagick
Save frames to image files
You need ImageMagick 6.3.5 (earlier versions will work, but will be slower)
and POGL 0.55_03.
ImageMagick 6.3.5 is currently available as a beta; it should be available as a stable release
next week or so. I added the following PerlMagick APIs:
Get('Scenes') - returns number of "scenes" in an IM image.
Get('Quantum') - returns IM's cache depth.
GetImagePixels() - returns a C pointer to IM's image cache.
SyncImagePixels() - syncs IM's image cache.
I've posted OpenGL::Image v0.00_1 to CPAN; since it's a new namespace,
it may take a while for it to be registered.
June 23, 2007
The ImageMagick folks added my new APIs to the 6.3.5 beta:
Get('Quantum') - returns IM's cache depth.
GetImagePixels() - returns a C pointer to IM's image cache.
SyncImagePixels() - syncs IM's image cache.
You can download it from their
I'll be posting a POGL update with an updated test app shortly.
June 22, 2007
Received an OK from the ImageMagick folks to add new APIs to provide
tight integration between POGL and PerlMagick.
Initial benchmarks show that ImageToPointer is about 188X faster that
either GetPixels or ImageToBlob:
ImageToBlob + glTexImage2D_s: 44.789 FPS
GetPixels + glTexImage2D_p: 45.595 FPS
ImageToPointer + glTexImage2D_c: 8614.444 FPS
Added the following APIs:
Get('Quantum') - returns IM's cache depth.
ImageToPointer() - returns a C pointer to IM's image cache.
SyncPointer() - syncs IM's image cache.
Need to complete some more tests, then will submit for IM's next release.
June 4, 2007
PyOpenGL's author, Mike Fletcher, posted comments on his SourceForge mailing
list explaining PyOpenGL's performance issues - mainly due to Python's
poor array handling performance, but also due to the fact that PyOpenGL
logs glGetError results on each call.
June 2, 2007
Received a suggestion from Samardzic that I might find significant performance
improvements switching from PyOpenGL v2 to v3.0.0a6 (still in alpha).
PyOpenGL v3 uses NumPy (Numerical Python) features; sounds like it has the potential
of possibly being faster than Perl?!?
Finally got some free time to try this out. Had to uninstall PyOpenGL v2, then
install Python's SetupTools module, then reinstall the ctypes module, then finally
install PyOpenGL v3.
Disappointed. I really expected to see significant performance improvement.
Instead, it was slower across the board. Perhaps because it's an alpha release?
Done with this Python diversion - time to implement more POGL features.
May 24, 2007
Received excellent reviews, feedback and suggestions from Taro Ogawa
and Aleksandar Samardzic regarding ways to improve my Trislam Python port.
Added a Python patch to support float division to eliminate float casting;
no performance difference.
Added Python's ctypes support per Smardzic's suggestion - got a 145% performance
improvement in Vertex Arrays... however this is still 170X slower than POGL's OGAs.
Couldn't build ctypes from source; luckily, found a Debian binary package that
Broadwell reported a bug in POGL's gl_pixelbuffer_size API, and sent a patch; fixed.
Perl vs Python benchmarks headlined on use Perl;
May 23, 2007
Noticed some postings claiming that OpenGL gaming engines based on Python
were better/faster than Perl... decided to do some benchmarks.
I had been avoiding learning Python - yeh, it's a cleaner language than Perl...
but it really doesn't add any features over those already supported in Perl.
Bit the bullet and ported Broadwell's Trislam benchmark to Python. Man -
Python has some significant shortcomings in terms of string handling.
Definitely prefer Ruby to Python.
Anyway - was surprised to see as much performance difference as there was. Huge difference
on Vertex Arrays - must be an error; will look into it.
Headlined on OpenGL.org
May 8, 2007
Ported Trislam to using POGL's OpenGL::Array objects (OGA) - big difference
in performance, as expected.
May 7, 2007
Heard from Geoffrey Broadwell yesterday; reported some problems on the site and
an SVN access issue; fixed.
Geoffrey has a game engine (PIGGE) based on SDL::OpenGL; introduced me to his
Ported Trislam to POGL; added new glXxxPointer_s APIs to simplify the port -
SDL::OpenGL uses packed Perl strings to pass buffer pointers... this is less
efficient than using POGL's OpenGL::Array (OGA) objects, which store data
as typed C arrays - reducing the need to convert/copy/cast data when passing
arrays to APIs.
Didn't expect to see as much of as performance difference as there is, without
using OGAs. Will need to do an OGA benchmark as well - should be a lot faster.
Unfortunately, don't see any VBO support in SDL::OpenGL.
Decided to add 2 new methods to OGA - bind and bound. This helps
abstract rendering for Vertex Arrays (VA) and Vertex Buffer Objects (VBO).
Just bind a GPU buffer to an OGA, and POGL will do the right thing when you
May 4, 2007
Been getting a lot of requests for POGL documentation/examples/etc - decided
to bite the bullet and put a site together.
Banged this site out in just over 2 days. Figuring out how to capture
OpenGL screen videos, and creating a dynamically streaming Flash player
was fun. Also fun figuring out how to get two HTML panes to scroll together
(for code comparison on benchmarks).
The rest was easy, using my LAMP-based
Turns out that my 3D Captcha
authentication system is apropos for this site.
Found GLgraph by Jonas Jermann, which uses Perl OpenGL - got permission to
post some of his images and a video.
April 26, 2007
It's now or never! Better to get something out the door, get feedback,
then plan for the next release.
Tried to get ActiveState to post my PPMs in their repository; they apparently
will not post modules that have external dependencies (like OpenGL); hurrumph!
April 23, 2007
Received a makefile patch for FreeBSD from Daiki Nomura; confirmation from Ilya
that POGL is working on his Solaris box; confirmation from various Mac developers
that POGL is working for them.
April 21, 2007
Was going to try to submit 0.55 to CPAN shortly; Cass Everitt pushing me to add
Multitexture support - 34+ new APIs - groan! But he has tested POGL on every nVidia
card out there - I owe him BIG TIME!
Banged out Multitexture support today.
April 17, 2007
Hope to submit POGL to CPAN by the end of the month - still hadn't heard from
any Mac developers - so I posted to several Mac mailings lists... got a lot
Sherm Pendley sent some patches for Mac OS; confirmed that POGL now works on Mac OS X;
April 13, 2007
Unable to contact anyone who has rights to update CPAN's OpenGL module - domains
for all the listed authors are defunct.
Found out that the last submittal was about 5 years ago.
Contacted PAUSE to request contributor rights to the module. Heard back from Ben Bennett,
who turned ownership over to me. He confirms that POGL works on Gentoo, ATI and Mesa.
April 12, 2007
Cass Everitt has been encouraging me to add VBO support for this 0.55 release;
banged it out this evening.
O'Reilly published a paid article on C vs Perl OpenGL performance I wrote last week:
April 2, 2007
Ilya has been testing POGL on his Solaris/Sunray boxes - great feedback and patches...
he's been a great help in getting this ready for release.
Decided to implement glVersion and alter Makefile.PL again to make it
smarter in terms of determining OpenGL version, extensions and lib availability.
March 26, 2007
Added support for Vertex and Fragment Program extensions.
Banged out C and Perl versions of a benchmark testing FBO and shader operations;
headline posted on OpenGL.org
The performance difference between Fedora and Ubuntu went away - probably due
to font engine implementations. Linux vs Windows performance differences still
there - even without POGL.
Surprisingly, getting some numbers where Perl is outperforming C - particularly
Can't figure out a way to install XP over Vista/Fedora/Ubuntu - without reformatting
and starting from scratch - aaarrrrrg!
March 19, 2007
Heard from Cass Everitt today - another early contributor to Perl OpenGL.
Cass reported a problem with installing on ActivePerl 5.6; fixed.
Turns out that Perl 5.8 and 5.6 have different threading models, and
requires separate builds.
March 17, 2007
First POGL headline!
March 16, 2007
First public release of POGL 0.55
Good pointers from Ilya regarding module distributions.
March 15, 2007
Ran some benchmarks using test.pl on NT, XP, Vista, Fedora and Ubuntu.
Blown away by the difference between Windows and Linux; but even more surprised
by the difference between Fedora and Ubuntu, as they are using the same nVidia
Need to do a C vs Perl benchmark to eliminate POGL as a factor in Windows vs Linux
March 8, 2007
Went bonkers and decided to implement 52 new OpenGL extensions over the past couple of evenings;
March 1, 2007
Good feedback/tips from several developers.
Had to significantly alter POGL's makefile to get it to build on
Linux (Ubuntu and Fedora).
February 14, 2007
Tested on NT and XP.
Set up an SVN repository for POGL.
January 28, 2007
Heard from one of the early Perl OpenGL contributors today - said to go ahead
January 27, 2007
I began looking in early January for a portable, opensource, OpenGL library for an online
service I was planning to build later in the summer. C libs required abstracting Windows'
wglGetProcAddress for OpenGL extensions - and required compiling.
Having used both Java and Perl in the past for building online services, and having
benchmarked those languages for several companies - I knew Java was not an option.
Python was a cleaner language than Perl, but I was aware that Python had a number of
limitations compared to Perl in terms of string handling. Ruby looked interesting,
but didn't seem ready for prime-time yet. Of all the languages, Perl has the largest
repository of opensource code to leverage.
The next step was to evaluate the several OpenGL Perl bindings that were available.
SDL sounded the most promising - however, I was not able to build/install it due to
all it's dependencies... plus all I needed was OpenGL - didn't need the rest
of SDL's media features. CPAN's OpenGL module was easy to build/install; in the end I
went with it.
The primary downside to this module is that it lacks support for recent GPGPU extensions,
particularly Framebuffer Objects (FBOs). I've spent most of this month attempting to contact
the original authors and contributors to collaborate on an update to support FBOs - and
have received no responses.
As such, I decided to make the enhancements for myself - and maintain my own branch,
Last weekend I rewrote the module's wglGetProcAddress abstraction, added an infrastructure
for supporting new extensions; this weekend I've added support for FBOs.
Decided to give the module a handle to distinguish it from other Perl bindings:
POGL - pronounced with a long O.