Jason Ferrara, of Jacquette Engineering for Research, the creators of Slither, on getting an OpenGL context of an IDL object graphics window:

IDL doesn’t provide any way to access or manage OpenGL contexts. IDL Object Graphics does use OpenGL to do its drawing though, so there must be valid OpenGL contexts floating around in there somewhere. It’s a reasonable assumption (and testing shows it to be true) that when the Draw method of an IDLgrModel object is called, the current OpenGL context is set to the window into which the model should be drawn.

This is from one of a series of articles about using this trick along with Slither to have PyMOL draw into an IDL object graphics window.

I’ve been trying to get a way to get an OpenGL context for awhile. I definitely will be keeping an eye out for future articles from Jacquette.

I’m not sure if I have mentioned this before, but I have a method of exporting simple object graphics scenes to a web page using x3dom. Check out this example of sending a graphics hierarchy containing a polygon (the cow data set from the IDL distribution) to an interactive display on a web page.

This is currently a proof of concept and works for views, models, and polygons with simple properties only, but expanding to more classes and properties should be straightforward. I have done similar things for various other new destination classes for outputs such as POV-Ray and anaglyphs.

Ronn Kling has published his Christmas card for this year:

2010 is an example of collision detection with IDL. In this card we have a user settable number of Christmas ornaments that bounce around the view. They not only bounce off the walls, they detect when a collision has occurred and bounce off each other. The technique is very similar to the 2008 Snownado where a single IDLgrPolygon is used with mutliple vertices. You can change the radii and restitution coefficient of the ornaments in real time. If your physics 101 class knowlege is a little fuzzy the restitution coefficient controls how energy is exchanged in collisions. For values less than 1.0 each collision loses energy and the balls slow down. A value of 1.0 is a perfect collision and the energy stays the same in the collision. Finally a value over 1.0 adds energy to each collision and everything speeds up.

You will also notice that we have two version this year, the Pre IDL 8.0 and IDL 8.0 and later. IDL has some great new syntax for objects and new things like lists. In the IDL 8.0 version the code uses the new list object , new object syntax and array indexing. The Pre IDL 8.0 is commented out in this version but is right next to the new code so that you can see what the changes are. If you don’t have IDL 8.0 then the Pre IDL 8.0 version will work fine for you.

Download for IDL 8.0 and pre-IDL 8.0.

ITT VIS is hosting a webinar about the IDL 8.0 function graphics system next Wednesday September 8, 2010 at various times (11 am Singapore time, 2 pm London time, or 2 pm New York time). I plan on attending to learn more about this system. Not sure if this will really replace direct graphics for me, but I plan to use it for quick stuff.

IDL 8.0 introduces an entirely new graphics interface. Currently, there is no name for this system except Graphics (am I supposed to say it capitalized when talking?), so I will refer to them as function graphics because all the routines are functions instead of procedures as in most direct graphics and iTools graphics routines. This new system is easy to use, interactive, programmatically accessible, and fairly complete even in this first release.

I can only just skim the surface of the capabilities of function graphics in this post. See the online help for more details.

To create a plot using function graphics, do:

IDL> p = plot(findgen(10), color=[255, 0, 0])

The plot can be annotated from the GUI interface, but it can also be modified via the return value p, an object which represents the newly created plot. You can get and set properties of the graphics object easily:

IDL> p.color = 'blue' ; or you could use [0, 0, 255]

The plot line automatically changes to blue.

IDL> print, p.color
0 0 255

From the command line, to find all the available properties of one of the graphics object returned from a function graphics routine, just print it:

IDL> print, p
PLOT <21317>
ANTIALIAS = 1
ASPECT_RATIO = 0.0000000
ASPECT_Z = 0.0000000
BACKGROUND_COLOR = 255 255 255
COLOR = 255 0 0
DEPTH_CUE = 0.00000 0.00000
[etc, rest of output omitted for brevity]

By the way, if you want to refer to colors by name in other uses in IDL, you can use the new !color system variable:

IDL> print, !color.blue
0 0 255

You can see a listing of all of the color names available by using HELP on !color:

IDL> help, !color, /structures
** Structure !COLOR, 147 tags, length=441, data length=441:
ALICE_BLUE BYTE Array[3]
ANTIQUE_WHITE BYTE Array[3]
AQUA BYTE Array[3]
AQUAMARINE BYTE Array[3]
[etc, rest of output omitted for brevity]

Note that function graphics can be used programmatically without any graphics windows appearing on the screen:

IDL> c = contour(dist(200), /buffer)
IDL> c->save, 'contour.png'

See the online help on a particular graphics object type to see its available methods, but most seem to have close, convertCoord, copyWindow, getSelect, order, print, refresh, rotate, save, scale, select, and translate.

The WIDGET_WINDOW routine provides a way to add a function graphics window to a widget application.

One of my favorite features in the new graphics API is that LaTeX escape sequences are built-in! For example,

IDL> p = plot(findgen(10), title='Some formula: $\mu = \epsilon^2 + \tau$')

(UPDATE: there is a TEX2IDL routine in the IDL distribution now that can be used independently of the function graphics routines.)

The following functions are part of the function graphics API: BARPLOT, COLORBAR, LEGEND, CONTOUR, ERRORPLOT, IMAGE, MAP, MAPCONTINENTS, MAPGRID, PLOT, PLOT3D, POLARPLOT, SURFACE, VECTOR, AXIS, ELLIPSE, POLYGON, POLYLINE, STREAMLINE, TEXT, and WINDOW.

There is much, much more to be said about function graphics, but hopefully this will get you started exploring. It will take more time to actually do some work using it to determine its shortcomings, but I think it is the most important feature of IDL 8.0.

Stay tuned for one last wrap-up article about IDL 8.0.

Recently, I’ve been wanting to create some timelines for various projects of mine. I needed something fairly flexible and I wanted the timeline to be generated from an input file, not from source code or a GUI. I settled on MG_TIMELINE which accepts an XML input file and generates a PostScript output file (which I can then convert to PNG or PDF, depending on what I need). While MG_TIMELINE is not a finished solution yet, it does handle my needs fairly well now.

To run the main-level example program, just put all the required files in the !path and type:

IDL> .run mg_timeline

The input file contains a top-level timeline element which specifies the start and end dates as well as the tick interval:

If you want a vertical line at the current date, put in a now element:

Currently, there are three types of items to place on the timelines: event, interval, and activity elements. Examples of these elements from the athletic.xml file are shown below. Events are at a specific date:

!4GRUB!XBoulder, CO

The color name can be any of the HTML color names. The level attribute specifies the height of the text for the level where 0.1 is the bottom timeline axis and 0.9 is the top timeline axis (I trying to think of ways to make this friendlier). An interval is similar except it has start and end dates:

An activity element specifies some value for each time period of the timeline. Below is a weekly activity which starts on the 17th week, so the value for the 17-19th weeks is 5, 20-22 is 6, etc.:

5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 10 10 10 11 11 11 12 12 12
13 13 14 14 14 15 15 15 10 10 10 5

It would be nice to add a sparkline visualization option for activities.

Here’s the source code, the data for the example, and the documentation. You will also need VIS_COLOR and its data. The output is available as a image or PDF.

In object graphics, it is very easy to rotate graphics atoms around the origin using the IDLgrModel::rotate method. But this rotation is always rotating around the origin. What if you want to rotate about a non-origin point? The technique is simple: translate the point of rotation to the origin, rotate, and translate back.

VISgrModel (docs) is a replacement for IDLgrModel that makes this a bit less of a hassle. It is created in the same way as IDLgrModel and used like this:

model->rotate, [0, 1, 0], 1, about=[-0.5, 0., 0.]

The default value for ABOUT is [0., 0., 0.], so it falls back to the standard IDLgrModel behavior.

I added texture maps for polygons and a VISgrPOVRayWindow class to the POVRay destination class for object graphics that I’ve mentioned before. The image to the left uses texture maps on an IDLgrPolgyon. It has a single direct light source to the right, so POVRay has cast a shadow on the right side of the left planet, making it entirely in shadow (I added a weak ambient light so that it could be seen at all).

The VISgrPOVRayWindow class acts just like IDLgrWindow except that it uses POV-Ray instead of OpenGL to render the graphics (i.e. it runs POV-Ray and loads the image back into IDL for you).

Download includes API documentation on how to use.

Ronn Kling just published his 2008 IDL Christmas Card. This year’s card is a “snownado”, a tornado of snowflakes which interact with 3-dimensional objects. The code demonstrates how to efficiently move around many polygons in object graphics. From Ronn’s description of the card:

If you are looking for a way to visualize rapidly moving 3D objects then<br />> this card may be a good starting place.

Check out previous year’s Christmas Cards also, they are all very interesting. Direct download.

A .sav file and API documentation for the POV-Ray object graphics destination that I’ve mentioned before are available here