I spent some time improving the POV-Ray destination for object graphics I talked about in a previous article. I can now produce visualizations of actual data (like the one on the right) using this destination and its related library of classes.

My goals for this destination are two-fold:

1. Create better renderings of pure IDL object graphics scenes (with no POV-Ray knowledge necessary).
2. Ability to use POV-Ray specific features using custom object graphics classes. These classes render in some way in IDL, but produce effects in POV-Ray that can’t be completely replicated in IDL.

I think the current VISgrPOVRay class supports objective 1 common 3-dimensional object graphics scenes, but lacks support for every property provided by the IDL library. Support for most properties can be easily done as needed.

The second objective requires creating new subclasses of classes in the IDL library with additional properties. For example, there is a VISgrPOVRayLight class which inherits from IDLgrLight class, but also provides support for the POV-Ray area light type. There is a VISgrPOVRayView which provides for features like focal blur in addition to the properties of the IDLgrView. There are also subclasses for grid planes, streamlines, and POV-Ray polygon graphics atoms as well as a finish attribute class. More classes can be added to support additional POV-Ray features as necessary.

POV-Ray is an open-source 3D ray-tracing tool (check out the Hall of Fame for examples of its use). After listening to Peter Messmer‘s excellent introduction to POV-Ray scene creation and seeing VisIt’s export to POV-Ray capability, I thought it wouldn’t be that hard to make an object graphics destination. To use it, create the scene as usual and then have the POV-Ray destination send its output to files for input into POV-Ray (the same as using IDLgrWindow).

The image shown is a direct export of a simple object graphics scene with an IDLgrPolygon (cow10.sav) with VERT_COLORS and SHADING=1, a directional light source, and a green IDLgrPolygon. Right now the POV-Ray destination supports ambient and directional lights, polygons, and surfaces. Only a few properties for polygons are supported: vertex colors, shading, and color. I’ll add more property and atom support as needed. The only problem right now is that POV-Ray uses a left-handed coordinate system, so I’m trying to think of the most elegant way to turn things around so that its scene matches the IDL scene.

I’m not sure what I’m going to do with the source code right now. I’ve added it to a “visualization library” that I’ve been using. Let me know if you are interested in trying it out.

UPDATE: it’s not hard to turn the POV-Ray output into a movie.

Revolution IDL is a nifty new tool created by Eduardo Iturrate at ITT VIS to create object graphics scenes. It can place text, images, various kinds of plots and polygons, and object graphics entities like clipping planes and lights into a scene. You can be translate, scale, and rotate all the objects in the scene as well as change their properties.

What makes this a great tool for learning object graphics is that it reverses the normal workflow from code to visualization. Revolution IDL can support a workflow where you:

1. use a visual interface to create the scene
2. display and edit the object graphics tree and the properties of the selected object, and
3. export the scene to IDL code that makes the scene.

The code exported is then an automated script to make the same visualization. From there it can then be modified to get the real data, produce a different kind of ouput, and/or be inserted into your system where it is needed. It would be nice if the iTools could do things like this, but until then Revolution IDL can get you started.

I was motivated to make a diagram of IDL’s operators by Mark Lentczner’s Periodic Table of the Operators in Perl. IDL doesn’t have nearly as many operators as Perl, so the IDL Periodic Table is much sparser. I added some operators not listed in the table of precedence in the online help. Order of precedence was determined empirically.

Here’s the table along with the code and data to make it: mg_make_op_table.pro (docs), mgffxmlsaloperators__define.pro (docs), and operators.xml. MGffXMLSAXOperators is an example of using IDL’s SAX parser (and object-graphics).

The main problem that programmers new to object graphics have is getting anything to appear on the screen (at least anything they recognize). Once you have your graphics appearing in a window, it’s pretty simple to change their properties, rotate them, make them dance the rhumba, etc.

There are various ways to scale your data into the view volume. This article will show one scaling technique I like for displaying 3D objects: using the [XYZ]COORD_CONV properties of a graphics atom object.

The code for the example is MG_CC_DEMO (doc) and a helper routine MG_LINEAR_FUNCION (doc).

Continue reading “A simple 3D object graphics example.”

This program is an example of using timer events to do a task in the background while allowing the the user interface to still respond to events. This technique requires the background task to be split into parts which are short enough for each part to complete quickly enough for a user to not notice a delay if he begins to interact with the interface. In other words, if each part of the task takes 0.1 seconds, then there is a potential delay of 0.1 seconds before the user interface will respond.

Here are the source and docs for the demo.

Continue reading “Timer events to process a task in the background.”

When rendering object graphics atoms with transparency, the order the atoms are rendered (i.e. the order the atoms are created and added to the hierarchy) determines what can be seen. You want to draw the atoms from back to front when the front items are transparent. The same principle holds true for iTools since they use object graphics.

Continue reading “Rendering order in the iTools.”

Anaglyphs are 3D images made from stereographic image pairs and viewed with red-blue glasses. I have a destination class, MGgrWindow3D, for the object graphics system that will automatically produce anaglyphs from regular 3D object graphics hierarchies (but not 2D plots and images). I’ve seen anaglyphs which are able to maintain color information; I might try to update the code to allow for that, but right now everything ends up greyscale.

Continue reading “Anaglyphs: MGgr3DConverter and MGgrWindow3D.”

A couple weeks ago, I wrote a demo program to view JPEG 2000 images as a “regular” widget program. Now I want to rewrite the same program as an “object widget,” in other words write methods of a class instead of normal functions and procedures. You need to already understand the basics of object-oriented and widget programming in IDL to follow along with this example. The following files are needed for this program: mgtilejp2__define.pro (doc), mgobjectwidget__define.pro (doc), mg_object_event_handler.pro (doc), and mg_object_cleanup.pro (doc).

Continue reading “Object widgets.”

I’m finding myself using object graphics over direct graphics more and more in my projects. My rule used to be to use direct graphics unless there was a compelling reason to use object graphics. This rule has now reversed itself, making object graphics the new default for me.

Here are the reasons which have lead to this:

1. Visualization properties are persistent. So after you create a visualization, it is easy to change one property of your visualization and redraw. This is particularly nice in widget programs.
2. Anti-aliased fonts.
3. IDLgrBuffer beats the True Color deficient Z buffer, hands down.
4. You want to make a 3D visualization with multiple items? In direct graphics, you can use the Z buffer to do hidden line removal, but then you are stuck in 8-bit color. Object graphics handles 3D graphics by default (of course, there are some minor snags with the interaction of rendering order and transparency, but nothings perfect).
5. Slice through anything with the CLIP_PLANES keyword.
6. Make anything transparent with the ALPHA_CHANNEL keyword.
7. Volume rendering.
8. It’s easier to create a visualization for one destination (like a graphics window) and then send it to another (like the printer or a Postscript file).
9. No system variables!
10. With the iTools using object graphics, in most situations you can create a quick visualization as fast as in direct graphics (or should I say, in as much typing). (See some of the advantages of direct graphics below for a situation you can’t do this.)
11. Since the MAP_PROJ_* routines were introduced in IDL 5.6, it’s possible to do mapping in object graphics.
12. With IDL 6.2 and a decent graphics card, displaying images is faster in object graphics.

Of course, there are some reasons still to use direct graphics.

1. While debugging a program, if you’re stopped at a line in the source code and want to make a quick visualization of one of the local variables, you’re options are limited. “Quick visualization” doesn’t really fit with hand coding object graphics, nor are the iTools an option in this situation since the event handlers for the widget program will not work. So I use direct graphics.
2. There are still some tricks with pixmaps in widget programs that I think look better in direct graphics.

Feel free to comment below on your own findings about object graphics versus direct graphics. Does anyone have another great reason to use direct graphics (besides the learning curve)?