3-D Programming with Python
Texturing mapping is the technique of taking image data, like a photograph, and “gluing” it to a polygon. Using textures requires converting the external texture images into one of the low-level internal formats supported by OpenGL. While the code required for setting textures in Python does not differ much from normal OpenGL code, Python does simplify the process of loading and manipulating texture image files.
The Python standard library includes rgbimg, a module for reading SGI imglib(.rgb) files. While this may seem like an obscure format, its simplicity allows its inclusion in Python's standard library without causing too much bloat. Using the GIMP or ImageMagick, you can convert images from formats like PNG, JPEG or TIFF to SGI imglib. The command rgbimg.longimagedata(file) will read and decode the specified SGI imglib formatted file and return it as a binary string of four-byte RGBA pixels. This data can be passed to OpenGL functions like glTexImage2D, using the format parameter GL_RGBA and the data type GL_UNSIGNED_BYTE.
Another useful module in the Python standard library is imageop. This module includes functions for cropping, scaling and grayscale conversions for images. The imageop functions operate on data in the same GL_RGBA/GL_UNSIGNED_BYTE format as the data returned from rgbimg.longimagedata().
In addition to wrapping the core libraries and toolkits, PyOpenGL also includes a number of utility functions to perform high-level tasks. Have you ever wanted to grab a still image of an OpenGL scene? You always can use programs that support screen capture, such as xv or The GIMP, but what if you want to grab a still at a specific point in time? Taking screenshots manually won't work if the program needs to run without user control, like a CGI script. You also can't grab a dozen stills a second manually to create a movie. PyOpenGL has a couple helper functions for automatically grabbing scene shots in various formats.
Listing 3 is an adaptation of the previous program that saves a PostScript image of the scene to disk, then exits. You can take a look at the image that was saved in Figure 1.
The scene is saved using the command
openglutil.glSaveEPS('ex3.eps', 240, 240)
The first argument is the name of the file to save to. The second is the width in pixels to capture, and the third is the height. Using the same syntax with the glSavePPM() command will save an image of the scene in the portable pixmap file format. Additionally, if you have compiled PyOpenGL with TIFF support, the command glSaveTIFF() is available for saving scene shots in the TIFF format.
PyOpenGL also provides a convenience wrapper for OpenGL's object selection or “picking” mechanism. The selection mode of operation in OpenGL automatically tells you which objects fall within a given region of the view screen. This means you can pass the selection mechanism to a point on the screen where a mouse click occurred, and it will tell you what object was clicked on.
Here are the basic steps for setting up the selection mechanism in PyOpenGL:
Write a method or function that draws each object in the scene wrapped in between a call to glPushName() and glPopName(). Pass a different integer as an argument to glPushName() for each independent object in the scene. OpenGL will use this value to indicate which objects were selected.
Set up the event handler for mouse clicks. The way this works depends on the toolkit you are using. In Tkinter, mouse-click event handlers are set up by passing a method or function reference to the bind() method.
Once a mouse click has occurred, pass the mouse x and y coordinates, along with a reference to the method or function created in part one, to the function OpenGL.GL.glSelectWithCallback(). This function will return a list of tuples of the form (near, far, names) where near and far represent integer depth values, and names is a tuple of the names passed in glPushName() for the selected objects. If no objects were selected, an empty tuple is returned.
Listing 4 demonstrates use of the selection mechanism in PyOpenGL. This demo draws a cube and a sphere on the screen. Experiment with holding down the Ctrl key and pressing the left mouse button with the pointer in different places.
The selection mechanism is the simplest way to perform this task, but it is by no means the only way. Another technique is to render the objects to a back buffer that OpenGL does not send to an output device. To do this, render each object using a different color. Once done, the back buffer should contain the 2-D rendering of the scene. By examining the color at a particular point you can determine which object was drawn in that region of the screen. This back buffer is called the feedback buffer in OpenGL.
Yet another method for object picking is to do the intersection testing by hand. This means you would have to project a ray from the view screen and test each object in the scene for intersection. Once you have found a list of intersected objects, you then must sort by depth values to see which was closest to the view screen. While this may offer more control over the process, it is an arduous task and is difficult to do efficiently in Python.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide