Kurt Schwehr Copyright (C) 2003 kdschwehr _at_ ucsd dot edu Viz Lecture Series Lecture 2 CONTINUING WITH OPENINVENTOR $Revision: 527 $ CONTENTS * SETUP OF XCORE * DEMO OF THE DAY - imgview 1:1 cores * REVIEW OF CEDIT * SYSTEM STATS - GR_OSVIEW & GMEMUSAGE * MORE GEOMETRIC SHAPES * CONVERTING ASCII LINES TO IV * TEXT - 2D and 3D * POLYGONS * TERRAINS FROM GMT FOR IV * TEXTURE MAPPING - PUTTING IMAGES INTO YOUR MODELS * GVIEW * PERFLY ---------------------------------------------------------------------- * SETUP OF XCORE This lecture introduces some of the simple programs available in the xcore package that make producing OpenInventor model files much easier. You will need to setup your account to be able to use these programs. You are now warned that xcore is still in initial development, so it has many rough edges. On the igpp fishnet SGI's, here is all that you have to do, since I have already built the programs. For bash, put this in your ~/.bashrc file: export PATH=${PATH}:/net/gdcspm/schwehr/`uname`-`uname -r`/bin For tcsh, put this in your ~/.cshrc or ~/.tcshrc file: setenv PATH ${PATH}:/net/gdcspm/schwehr/`uname`-`uname -r`/bin Then if all is well, on the SGI's you will see the following: which xcore-ivview /net/gdcspm/schwehr/IRIX64-6.5/bin/xcore-ivview On a Sun you see no output for the above xcore-ivview, since it does not exist for the Sun's right now. For those of you with your own SGI's, here is what you need to do to install xcore. Note that xcore-0.6 will not Make sure that you have the SGI freeware CD installed, as it provides gcc and g++. Use a web browse to check out http://schwehr.org/xcore wget http://schwehr.org/xcore/xcore-0.6.tar.bz2 bunzip2 xcore-0.6.tar.bz2 tar xf xcore-0.6.tar cd xcore-0.6/xcore-iv make # Ignore the error with quakeview cd IRIX64-6.5 /bin/rm *.[oa] mkdir -p ~/IRIX64-6.5/bin mv * ~/`uname`-`uname -r`/bin/ For bash, put this in your ~/.bashrc file: export PATH=${PATH}:${HOME}/`uname`-`uname -r`/bin For tcsh, put this in your ~/.cshrc or ~/.tcshrc file: setenv PATH ${PATH}:${HOME}/`uname`-`uname -r`/bin * DEMO OF THE DAY - imgview 1:1 cores Last time, we took a look at imgview and saw how it is good for large images. With large screens such as the 21ftx8ft viz center display, we can do some novel things. We can display geologic maps and samples at 1:1 scale. In this example, we will use xdpyinfo to figure out the pixel size of the display. Unfortunately, xdpyinfo does not return the correct size, but does return the correct pixel dimensions. If you create a 100x100 pixel image and measure the size when displayed on the screen, you can calculate the pixel size on the screen. In this case I created a picture of five piston cores at 1:1 vertical scale, but stretch to be a bit wider to improve viewing. Take a look at the image: imgview 1to1cores.jpg To see the image characteristics: imginfo 1to1cores.jpg Sub-image: 3 (default) Dimensions (w,h,z,c): 3200, 600, 1, 3 Page Size (w,h,z,c): 3200, 600, 1, 3 Data type: unsigned char Dimension order: interleaved Color model: RGB Coordinate space: upper-left Statistical Min/Max: 0 - 255 Display Min/Max: 0 - 255 Data Compression: JPEG If you look at the info, the image is 3600 pixels wide and 600 tall. The screen is taller than 600 pixels. There are black and white bars across the top that are each a meter long. Top of the cores is on the left. * REVIEW OF CEDIT I didn't cover cedit last time, even though it was in the lecture notes, so I will cover it this time. You will need to be able to choose colors for many an object in OpenInventor, so see the previous lecture for instructions for cedit. * SYSTEM STATS - GR_TOP, GR_OSVIEW & GMEMUSAGE There are a number of very hand commands for finding out how much of an SGI's resources are being utilized. The first on is an adaptation of the traditional unix top program that displays a list of the most active processes on a computer. Try just running "top" in a shell on just about an computer and see a list of what is going on that refreshes every 20 seconds or so. Type a "q" to quit out of the program. SGI's version is: gr_top & This will give you separate graphical window. One of the things top is good at showing you is the amount of RAM and swap being used by each process. This is particularly important for view very large 3D models. If the computer is running out of memory and having to use swap space, your rendering will get extremely slow. Also, it is often possible to reduce the memory footprint a bit and get much better cache usage. For more details, see [FIX: insert reference]. To look closer into how much memory programs are using, SGI has a really excellent tool: gmemusage & Just click on programs and what what happens as you start an stop programs. See what happens when you load a model in a program such as fledermaus. The last inspection program is probably the most commonly used monitoring tool. gr_osview provides a real-time graphical view of a number of system parameters, but most importantly CPU usage. It can also show you overall memory usage, disk space and a number of other parameters. To get the normal view, run it this way: gr_osview -a For more monitoring jobs, consider: RTI's Scope/Probe (they have great deals for students), which can graph variables inside of running programs in real time. and http://freshmeat.net/browse/229/?topic_id=229&orderby=&filter=862 gmem, Xosview, xps, etc. * MORE GEOMETRIC SHAPES OpenInventor provides a number of basic shapes that you will probably use often in putting together models. You can use them to compose various shapes, for example arrows, compasses, etc. Here is a list of shapes and the man page name for each (only available on arad3d): Sphere man SoSphere Cube man SoCube Cone man SoCone Cylinder man SoCylinder The following example illustrates each of the 4 shapes. It also shows how to use the SoMaterial node to change colors and transparency. #Inventor V2.0 ascii Separator { BaseColor { rgb [ 0 1 1] } Translation { translation 10 0 0 } Sphere { radius .5 } } Separator { BaseColor { rgb [ 1 1 1] } Translation { translation 5 0 0 } Cube{ width .2 height .4 depth .6 } } Separator { BaseColor { rgb [ 1 1 1] } Translation { translation -6 0 0 } Cylinder { radius 1 height 2} } Separator { BaseColor { rgb [ 1 1 1] } Translation { translation -3 0 0 } Cylinder { parts (BOTTOM|TOP) radius 1 height 2} } Separator { BaseColor { rgb [ 1 0 1] } Translation { translation 0 0 -5 } Cone{} } Material { diffuseColor [ 0.6 0 0.3 ] ambientColor [ 0.6 0 0 ] specularColor [0.6 0 0 ] } Separator { Translation { translation 0 0 5 } Cone{parts (SIDES) bottomRadius .5 height 2 } } Material { transparency 0.5 } Separator { Translation { translation 0 0 0 } Sphere{} } * CONVERTING ASCII LINES TO IV In the previous lecture, we looked at how to create line sets in OpenInventor. For this class, we will use a small program from the xcore toolset to turn a list of fault lines into an OpenInventor lineset without having to edit the file by hand. The source file is available only on sioviz.ucsd.edu, so I have put it in: ~schwehr/Lecture2/faults_CA_lon_lat.dat Here is the whole process: cp /omaha/demos/faults/make_faults/faults_CA.dat . head faults_CA.dat awk '{print $2,$1,0}' faults_CA.dat > faults_CA_lon_lat.dat line2iv faults_CA_lon_lat faults_CA ivview faults_CA.iv So now, let's go through what happened in the above five lines. To start with, we want to copy the file into our working directory and take a look at what the format is. "head" shows us the first 10 lines of the file: 9999 9999 32.9312 -115.5496 32.9142 -115.5419 32.9029 -115.5358 32.8890 -115.5276 32.8701 -115.5162 32.8535 -115.5034 32.8372 -115.4880 32.8214 -115.4756 32.8069 -115.4646 The original data file consists of lines that start with a marker of "9999 9999" and are followed by points along the line in a latitude, longitude format. In this case it is easy to guess the format, since latitude only runs from -90 to +90. The line2iv program is not to smart, so we must convert the file to longitude, latitude, depth format. We do that by using awk to print out the 2nd column followed by the first, to get: 9999 9999 0 -115.5496 32.9312 0 -115.5419 32.9142 0 -115.5358 32.9029 0 -115.5276 32.8890 0 -115.5162 32.8701 0 -115.5034 32.8535 0 -115.4880 32.8372 0 -115.4756 32.8214 0 -115.4646 32.8069 0 Now that we have an input file in the right format, we simply convert the file to an OpenInventor file and view it. You should see some of the major California faults that give you a sense of the shape of the state. For 3D faults of California: cp /omaha/demos/earthquake_point_data/raw_data/Cal_flt.dat.xyz . line2iv Cal_flt.dat.xyz Cal_flt ivview Cal_flt.iv That's it! * TEXT - 2D and 3D The next thing that people often would like to do is to label objects in the 3D world. There are two easy ways in OpenInventor: 2D and 3D text. 2D text presents the viewer with text that is always facing forward and it renders quickly. However, it does not do well if there are a large number of 2D text objects in the scene or with zooming in and out if you would like text to only be viewed when close to the object. 3D text puts actual 3D drawn text in the model that rotates and scales with the rest of the scene. Here are two simple examples of OpenInventor text files: #Inventor V2.0 ascii Text2 { string "2D Hello" } Text3 { string "Hello 3D world" } xcore provides a simple way to added text to a map. Here is an example that adds city names to the California fault map: Create a "towns.dat" file: 32.5519 -117.0422 "San Ysidro" 32.5772 -116.6267 "Tecate" 32.7153 -117.1564 "San Diego" 32.8472 -117.2733 "La Jolla" 32.9594 -117.2644 "Del Mar" 33.0786 -116.6011 "Julian" 33.1192 -117.0856 "Escondido" 33.1958 -117.3786 "Oceanside" 33.2558 -116.3742 "Borrego Springs" 33.3228 -116.8778 "Palomar Mountain" 33.3811 -117.5722 "San Onofre" 33.7878 -117.8522 "Orange" 33.9533 -117.3953 "Riverside" 34.0522 -118.2428 "Los Angeles" 34.2783 -119.2922 "Ventura" 34.4208 -119.6972 "Santa Barbara" Then use the xcore xytext2iv command: xytext2iv towns.dat towns Then view the towns and the faults at the same time: ivview towns.iv faults_CA.iv * POLYGONS So far, we have only created either fixed shapes or lines. What if we need to create objects with arbitrary surfaces? This is especially important for creating terrains and bathemtry. With computer graphics, it is always best to stick to 3 sided triangles and avoid polygons of hire order. Please try some examples with 5 or more sides and you may see some strange artifacts. First a simple triangle: man SoCoordinate3 man SoIndexedFaceSet #Inventor V2.0 ascii Separator { Coordinate3 { point [ 0. 0. 0, 1. 0. 0., 0. 0. -1., ] } IndexedFaceSet { coordIndex [ 0, 1, 2, -1, ]} } In the above file, the Coordinate3 object defines the corners of the triangle. OpenInventor indexes from 0 like the C programming language, not from 1. So we specify in IndexedFaceSet the indexes to each corner. This way when you are building a mesh of triangles, that shared points are only stored in memory once and the index is reused. Notice that only one side of the triangle is visible. If you look at the backside, the triangle disappears. This is called back face culling. This is for performance. The front verses back face is defined by the order of the points in each triangle: clockwise or counter clockwise. Now for a square, so you can see how to have multiple polygons in one IndexedFaceSet. Notice that "-1" for an index defines the end of the polygon. #Inventor V2.0 ascii Separator { Coordinate3 { point [ 0. 0. 0.0, 1 0.0 0.0, 0. 0. -1, 1 0.0 -1 ] } IndexedFaceSet { coordIndex [ 0, 1, 2, -1, 1, 3, 2, -1 ]} } * TERRAINS FROM GMT FOR IV So now that we know how to make polygons, let's go straight for making terrains from gmt grd files. Being that we are at Scripps, many people have multi-beam data that has been brought in from a ship via mbsystem. How many hours have you spent ping editing? You can also use fledermaus to export an ASCII xyz file and jump in part way through this example. Here I will use some em1000 bathymetry from the Eureka/Humboldt area of northern California from the STRATAFORM project. Bring in the data to a grid file will be another lecture. ls -l terrain.grd grdinfo terrain.grd terrain.grd: Title: terrain.grd: Command: grdsample Eureka.grd -N70/70 -Gt-5.grd terrain.grd: Remark: terrain.grd: Normal node registration used terrain.grd: grdfile format # 0 terrain.grd: x_min: -124.6 x_max: -124.1 x_inc: 0.00724638 units: user_x_unit nx: 70 terrain.grd: y_min: 40.7 y_max: 41 y_inc: 0.00434783 units: user_y_unit ny: 70 terrain.grd: z_min: -566.992 z_max: -37.3493 units: user_z_unit terrain.grd: scale_factor: 1 add_offset: 0 Now convert the grd to a regular ASCII xyz file. The terrain command only handles regularized xyz files. That means the points with no data should have a NaN (not a number) entries, which luckily is the default for grd2xyz: gmtset D_FORMAT = %l.10g # Fix precision problem with grd2xyz grd2xyz terrain.grd > terrain.xyz head terrain.xyz -124.6 41 NaN -124.593 41 NaN -124.586 41 NaN -124.578 41 NaN -124.571 41 NaN -124.564 41 NaN -124.557 41 NaN -124.549 41 NaN -124.542 41 NaN -124.535 41 NaN All we have to do now is create the terrain file for OpenInventor: terrain terrain.xyz terrain.iv ivview terrain.iv That's it! * TEXTURE MAPPING - PUTTING IMAGES INTO YOUR MODELS So you might have a photograph or graph that you want to put into your 3D model. It's actually pretty easy if you have a template to follow. Let's start out by putting a graph from gnuplot into the model. First we need to create a gnuplot script to plot the core data: # -*- shell-script -*- # Kurt Schwehr - Dec 2001 # gnuplot of corelog data # set xlabel "Depth (m)" set ylabel "Gamma (cps)" set data style fsteps set grid set key left set yrange [6000:16000] # Plot Gamma set terminal postscript landscape enhanced color set title "02PC-IV(4) Gamma\nUofW Geotek MST" set output "02pc-IV-gamma.ps" plot '02pc-IV.dat' using 1:7 with lines This gnuplot file will plot out column 1 verses column 2 and output a postscript file. You are on your own to learn more about gnuplot. And now for some data to plot: 0.000 1 0.00 2.92 102.15 0 18318 22.04 0.040 1 4.00 2.88 102.15 0 8660 22.04 0.080 1 8.00 4.76 102.15 0 8400 22.04 0.120 1 12.00 -1.15 102.15 0 8426 22.04 0.160 1 16.00 -1.07 102.15 0 8568 22.04 0.200 1 20.00 -1.14 102.15 0 11021 22.05 0.240 1 24.00 -1.17 102.15 0 9459 22.05 0.280 1 28.00 -1.34 102.10 0 9141 22.05 0.320 1 32.00 -1.39 102.15 0 9110 22.05 0.360 1 36.00 -1.40 102.10 0 12389 22.05 0.400 1 40.00 -1.52 102.15 0 9300 22.05 0.440 1 44.00 -1.57 102.15 0 9538 22.06 0.480 1 48.00 -1.65 102.10 0 10921 22.06 0.520 1 52.00 -1.47 102.15 0 9078 22.06 0.560 1 56.00 -1.63 102.10 0 10136 22.06 0.600 1 60.00 -1.57 102.15 0 8994 22.07 0.640 1 64.00 -1.48 102.10 0 9467 22.07 0.680 1 68.00 -1.52 102.10 0 9000 22.07 0.720 1 72.00 -1.31 102.10 0 15519 22.08 0.760 1 76.00 -0.92 102.10 0 8941 22.08 0.800 1 80.00 0.08 102.15 0 9354 22.08 0.840 1 84.00 1.13 102.20 0 10114 22.08 0.880 1 88.00 2.24 102.25 0 8851 22.08 0.920 1 92.00 3.31 102.20 0 8762 22.09 0.960 1 96.00 4.01 102.30 0 8400 22.09 1.000 1 100.00 4.24 102.20 0 10370 22.09 1.040 1 104.00 4.01 102.20 0 8459 22.10 1.080 1 108.00 3.78 102.35 0 8486 22.10 1.120 1 112.00 3.95 102.25 0 8294 22.10 1.160 1 116.00 4.39 102.20 0 8428 22.14 1.200 1 120.00 3.70 102.20 0 8696 22.15 1.240 1 124.00 2.46 102.15 0 8825 22.15 1.280 1 128.00 1.47 102.25 0 8554 22.15 1.320 1 132.00 0.54 102.20 0 8653 22.15 1.360 1 136.00 -0.50 102.20 0 8401 22.15 1.400 1 140.00 -0.57 102.20 0 8488 22.15 1.440 1 144.00 7.78 102.25 0 8156 22.16 1.480 1 148.00 5.39 102.20 0 8357 22.16 Now we have a postscript plot that we can look at but can not put into OpenInventor. It doesn't know anything about postscript. It does, however, know about gif's (and now that gif's are legal in the US)... # Use ghostscript/ghostview to take a look: gv 02pc-IV-gamma.ps # convert to gif using pnmtools pstopnm -stdout 02pc-IV-gamma.ps | pnmrotate -90 | ppmtogif > 02pc-IV-gamma.gif imgview 02pc-IV-gamma.gif # or xv 02pc-IV-gamma.gif # Find out the size: pstopnm -stdout 02pc-IV-gamma.ps | pnmfile stdin: PPM raw, 553 by 792 maxval 255 We can take this gif and create an IV file that brings in the gif as a texture. You need to change the values in the Coordinate3 node to match the image size. As long as you maintain the aspect ratio, you can choose any size you like. #Inventor V2.0 ascii # Container for gif image 792 x 553 Separator { Complexity { value 1.0 textureQuality 1. } Coordinate3 { point [ 0. 0. 0.0, 792 0.0 0.0, 0. 0. -553, 792 0.0 -553 ] } Texture2 { filename "02pc-IV-gamma.gif" model DECAL } TextureCoordinate2 { point [ 0.0 1.0, 1.0 1.0, 0.0 0.0, 1.0 0.0, ] } IndexedFaceSet { coordIndex [ 0, 1, 2, -1, 1, 3, 2, -1 ]} IndexedLineSet { coordIndex [ 0, 1, 3, 2, 0 ] } } * SCENE GRAPHS - GVIEW gview is a great sample program that can help you learn about scene graphs. It can also help you to fine tune your scenes. It does not come built with OpenInventor on the SGI which is a real shame. If you are on IGPP fishnet SGI's and have setup your path as described above, you already have gview in your path. Here is how I built the program. cd /tmp cp -r /usr/share/src/Inventor . cd Inventor/demos/gview smake strip gview mv gview gviewIcons.iv ~/`uname`-`uname -r`/bin/ Now run gview on any OpenInventor model you might have, e.g.: gview towns.iv * PERFLY SGI makes another software library called Performer that is much like OpenInventor, but is optimized for super performance at the expense of easy of use. Performer knows how to load OpenInventor format files. You may want to check out your models in the Performer equivalent of ivview: perfly -help perfly faults_CA.iv towns.iv Type "?" while running for keyboard commands