In order to enable it, you need to edit /etc/X11/xorg.conf and add the following to the Module section:

Load "extmod"

 
Time passes...

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.

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 glutCloseFunc callback.

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.

I've added:

• glutGameModeString
• glutEnterGameMode
• glutLeaveGameMode
• glutGameModeGet

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:

$Window_State = glpFullScreen();
glpRestoreScreen($Window_State);

Note: certain X11 window managers do not handle full screen correctly - the system menubar remains visible.

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

glutSetOption(GLUT_ACTION_ON_WINDOW_CLOSE,GLUT_ACTION_GLUTMAINLOOP_RETURNS);

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.

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!!!!!!!!!!
YOU ARE AMAZING!!!

Mitchell - you are amazing for getting this to work - thanks for demonstrating yet another use of POGL!

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.

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 OpenGL::Array - 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

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 and projections.

Two in one day!

I was made Open Directory Project (dmoz.org) editor for:

Good fit for POGL.

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!

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.

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.

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".

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 process.

I'm the ODP editor for a number of Perl and openGL sections.

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.

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.

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.

Finally got around to fixing my benchmark/build machine. Good news, it now multi-boots to XP/Vista/Fedora6/Ubuntu-Gutsy.

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.

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.

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 distribution.

Aaarrrgh!

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.

Started my new job as CTO of Appscio.

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 slow. Bummed.

Contacted by a Google recruiter for a senior role. Interested, but informed them that I'd already accepted a position at Appscio.

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 programming.

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.

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.

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
• abs
• negate
• add (decided no need for sub)
• mul
• div - NOP for divide by 0 conditions
• pow
• mod
• min
• max
• sin
• cos
• tan
• atan2

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.

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.

I added the following OGA APIs for vector transforms:

oga->update(@columns)
oga->affine(@mat)

Example: $oga->update(1.25,undef,'rand(1.0)');

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 shortly.

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 transforms.

Received reports from a couple fo developers that they are having problems using the gluTess APIs.

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.

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
• Implemented GL_ARB_point_parameters
• Implemented GL_ARB_multisample
• Implemented GL_ARB_color_buffer_float

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

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.

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

Released OpenGL-Image v1.02 with the following changes:

Geoff Broadwell

• 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.

grafman

• Fixed version number for OpenGL::Image::Common
• Enhanced hex_tile.pl
• 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 Consulting Partner

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.

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 glGetIntegerv_p(GL_MAX_RENDERBUFFER_SIZE_EXT) - will add it to the next POGL release.

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!

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
• Added GetPowerOf2
• Updated SyncOGA in Magick.pm to handle image resizing.
• Added hex_tile.pl screensaver

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 in OpenGL::Image::Targa.

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.

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.

Strands and Hair

Full-day course on modeling, animating and rendering hair.

Challenges

• 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.

Fluids

Bubbling and Frothing Liquids

Bubble Flow Challenges

• 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.

Perception and Graphics

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.

X3D BOF
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 (the foundation for JavaScript, ActionScript, etc).

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, among others.

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.

Advanced Real-Time Rendering in 3D Graphics and Games

Voxels Make a Comeback

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).

High Resolution Line Drawing

Objectives:

• 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
• Single texture

Solution: store outside edge distance in the alpha channel

Results:

• Fast, clean, cheap
• Visually pleasant
• Alpha channel can be reused for boundary glow and drop shadows

OpenSceneGraph BOF

Holographic Elements (hogels)

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.

Perception and Color

Fluorescent Imaging

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.

Visual Equivalence

Perceptual metrics:

• 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.

Material Recognition

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.

GPGPU

GPUs are not just about graphics - they are processors tuned for optimized processing of large arrays/matrices of data.

+$500M GPUs shipped per year; GPGPU uses:

• Data analysis
• Data search/sorting
• Research physics
• Game physics

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.

Question: if your GPU is already doing graphics-intensive processing, doesn't GPGPU "rob Peter to pay Paul"? Response: 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

GPGPU Searching and Sorting

Bitonic merge sorts are over twice as fast on GPUs than generation-comparable CPUs.

Terabyte Sorting
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.

Job Fair

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.

Exhibitions in Halls E-G

The normal exhibitor fair. I'm not here to review products - I'll leave that for the other blogs.

Food Vendors

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.

Electronic Theater

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.

Back to Basics

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.

Notable Mentions

ALL the presentations were inspired, technically impressive and creatively challenging. Of special note for me (from the Tuesday Matinee)...

No Time for Nuts - Scrat continues to be a Pixar favorite, this time in a time-travelling short.

En Tus Brazos - a beautiful and emotional rendention of partners in a Tango of memories.

A Gentleman's Duel - socially crude, but well-rendered and FUNNY. Men at their best/worst.

The Saints Are Coming - You've seen this U2 / Green Day music video - still moving.

The Itch - short - simply brilliant.

Raymond - you have to be a geek to appreciate this one - hilarious.

Portal - THE MOST AWESOME 1ST PERSON SHOOTER WEAPON!

Adobe / Maxon Party

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.

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.

Electronic Theater

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.

AJAX 3D

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).

Uses:

• Catalogues
• GIS/mapping/navigation
• Gaming, multi-user communications
• Immersive UI vs 2D desktop navigation

Multi-body Collision Modeling

Minimize solid-body oscillations by:

• calculating volume and form divergence separately
• calc friction separately, after pressure calcs

Database Analytics

Using parallel computation and commong web search techniques for user-controlled multi-body motion:

• Opt-in/out trajectories
• Searching/sorting by velocity, duration, collisions, etc
• Interactive user criteria and queues

Spacial and Temporal Culling

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

Viscoplatsic 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.

Steel Drums

Today's lunch accompanied by the light percussive sounds of Jamaica.

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.

DirectX 10

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?

DirextX 10 Highlights

• 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 GL_EXT_geometry_shader4 extension on DirectX 10 compliant cards.

Geometry Shaders

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.

Texture Arrays

You can now index 2D arrays (textures), for both reading and writing/rendering. This simplifies layering, combining or switching between textures

Resource Views

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.

Memory Management 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.

Per-Pixel Lighting Demos show that per-pixel lighting increases dynamic range, better detail and improved shadows. Presenter recommended using instancing over geometry shaders when possible.

Flight Simulator X

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.

Content Pipeline
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.

Sun at SIGGRAPH

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.

Emerging Technologies Gallery

The gallery is upstairs in Ballroom 20.

Calm Before the Storm

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.

Registration Center

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 ;^)

Wireless Access
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).

Shuttles
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.

Digital Performances - UCSD
The UCSD California Institute for Telecommunications and Information Technology (Calit2) Has a 4K (8 mega-pixel) theatre - worth checking out.

Walking Into a Leonardo Masterpiece

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.

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.

I spotted the following, posted on PerlMonks in reply to my POGL 0.56 and OpenGL-Shader posting - attaboy's much appreciated! :)

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.

BTW - if you register on ohloh.org (an opensource tracker), you can add my projects to your "stack":

• POGL
• OpenGL-Image
• OpenGL-Shader

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 shading languages.

Note: I'll be reporting from SIGGRAPH on this blog next month. Stay tuned!

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.

Added POGL support for the following OpenGL extensions:

• GL_EXT_texture_cube_map
• GL_ARB_shader_objects
• GL_ARB_fragment_shader
• GL_ARB_vertex_shader
• GL_ARB_shading_language_100
• GL_EXT_Cg_shader

Implented a new extensible OpenGL::Shader module to abstract loading/managing OpenGL shaders. Testing; should release soon.

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

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 module.

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.

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.

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 beta respository.

I'll be posting a POGL update with an updated test app shortly.

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.

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.

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.

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 worked.

Broadwell reported a bug in POGL's gl_pixelbuffer_size API, and sent a patch; fixed.

Perl vs Python benchmarks headlined on use Perl;

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

Ported Trislam to using POGL's OpenGL::Array objects (OGA) - big difference in performance, as expected.

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 Trislam benchmarks.

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 call glXxxPointer_p.

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 gcSite framework. 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.

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!

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.

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.

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 of responses.

Sherm Pendley sent some patches for Mac OS; confirmed that POGL now works on Mac OS X; fast turnaround!

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.

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: Perl.com

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.

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 on Windows.

Can't figure out a way to install XP over Vista/Fedora/Ubuntu - without reformatting and starting from scratch - aaarrrrrg!

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.

First POGL headline!

First public release of POGL 0.55

Good pointers from Ilya regarding module distributions.

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 drivers.

Need to do a C vs Perl benchmark to eliminate POGL as a factor in Windows vs Linux performance.

Went bonkers and decided to implement 52 new OpenGL extensions over the past couple of evenings; rewrote test.pl

Good feedback/tips from several developers.

Had to significantly alter POGL's makefile to get it to build on Linux (Ubuntu and Fedora).

Tested on NT and XP.

Set up an SVN repository for POGL.

Heard from one of the early Perl OpenGL contributors today - said to go ahead to contribute.

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, if necessary.

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.