TerraForm3D Plasma Works 3D Engine & USGS Terrain Modeler Heather Jeffcott Craig Post Deborah Lee Soltesz Trent D’Hooge

Team Organization  Heather Jeffcott – Programming Support  Craig Post – Plasma Works 3D Engine  Deborah Soltesz – USGS Terrain Modeler  Trent D’Hooge – Parallelization

Overview  Design of Two 3D Packages  PlasmaWorks – 3D Engine 3D Game Engine with a variety of special effects to choose from.  USGS – Terrain Modeler User interface and high-quality parallelized image renderer which handles large image data files

Scheduling and Organization  Good Stuff  Meetings Short meetings held often Business first, then brainstorm  Records Minutes Regular Status Reports Meaningful Documentation  Deadlines Early but reasonable – realistic! Built-In lead time

Scheduling and Organization  What could have been better….  Published a monthly calendar along with the Status Reports Keep better track of upcoming projects and deadlines  Scheduling around high stress times  mid-terms  unforeseen events documentation for this project papers, programs, and other large assignments in other classes

Plasma Works 3D Engine Craig Post

Plasma Works 3D Engine - Craig Post7 PW3D: Architecture  Overview: Object VertexAnimationsTexture Renderer CameraTextures Lights Pointer to objects to render

PW3D: Architecture Analysis  Lessons Learned:  Integrating functionality into one class made up of multiple subclasses is best  Inheritance is GOOD!  Due to OS, it is difficult to make a completely independent renderer  An event driven architecture might work better than a looping architecture  Adding functionality to the renderer is difficult

PW3D: Design Methodology  Design Methodology Used: Prototype  Benefits Good for learning Easy to add on to Easy to see real implementation  Drawbacks Easy to get stuck in paradigms Tough to throw away work

PW3D: Tools and Languages  Tools used: OpenGL  Benefits: much easier than DirectX more help available handles a lot of the behind the scenes work for you  Drawbacks: not as widely supported in gaming only handles graphics, nothing else not strictly game oriented

PW3D: Coordinate Systems  Coordinate systems are very important for retaining system consistency  It is important to learn your coordinate system inside and out very early on

PW3D: Final Comments  Overall Lessons Learned:  Mathematics is much more difficult when trying to apply it  It is difficult to take an algorithm on paper and convert it to code  There are too many goodies to add in one semester

Deborah Lee Soltesz Terrain Modeler

USGS Terrain Modeler - Deborah Lee Soltesz Package Interface View Image Manager Manages input image files GUI Manages user input, data manipulation, image rendering and screen display Media Output Manages output image rendering and files Request: Create media of specific type Give: transformation matrices pointer to Image Manager Request: Retrieve data from a specific region of a terrain or overlay image Set detail level Request: Open file(s) Retrieve data from a specific region of a terrain or overlay image Set detail level

USGS Terrain Modeler - Deborah Lee Soltesz Design & Implementation  Iterative Prototyping  Build up and test functional classes and packages iteratively allows more strenuous, automated testing work bugs out before adding more complexity  GUI Prototyped works out bugs before adding in complex underlying functional packages tests usability and fertilizes brainstorming “Eye Candy” factor

USGS Terrain Modeler - Deborah Lee Soltesz TerraGUI TerraGUI serves as the user interface and on-screen 3D manipulation package

USGS Terrain Modeler - Deborah Lee Soltesz TerraGUI User Interface  3D Engine / 3D Engine Lite  Great idea - didn’t work Terrain Model functionality did not apply to needs of 3D Engine  Prototyping helped make the decision to make two separate screen renderers early in the process  Terrain Reduction Algorithm  Simple “pick every n points” vs. picking points that best add definition great algorithm, but came too late

USGS Terrain Modeler - Deborah Lee Soltesz ImageManager serves as a generic interface to a plethora of image file formats ImageManager write TGA

USGS Terrain Modeler - Deborah Lee Soltesz MediaOutput handles saving transformations set in TerraGUI to high- resolution imagery, digital video frames, or VRML MediaOutput

USGS Terrain Modeler - Deborah Lee Soltesz 3D File Rendering  Original Plan: write a renderer  Optimized to data and purpose  Open Source - can be tweaked  New Plan: POV-Ray  Open Source - can be tweaked  Has parallelized version: PVM-POV  Fits data and purpose fairly well, but has weaknesses

USGS Terrain Modeler - Deborah Lee Soltesz 3D Rendering: Conclusion  POV-Ray should have been part of the original plan  Time  Time could have been spent better making improvements to POV-Ray improve file input management add MIPS image format as input/output type interface directly to POV-Ray libraries instead of making cheesy system call

USGS Terrain Modeler - Deborah Lee Soltesz Issues  Deb’s development environment  finding an OpenGL system to work on installing necessary hardware, software, libraries, etc. should have started sooner

Parallel Processing Trent D’Hooge

ProtoType Method  Allowed for learning MPI and how to best set up and use a Beowulf Cluster  Allowed for testing of different ideas from algorithms for splitting up the work to communication between computers  Brought forth issues in networking and memory management

Resources  NFS  Allowed for the sharing of data between computers at the kernel level  MPI and PVM  Allows computers to pass messages back and forth  POVRAY  Software that can run across multiple computers for 3D rendering

Implementation  Found that PVM POVRAY would do the 3D rendering and would run in parallel  Very little change had to be made to the cluster  Works very well for images that can be buffered  Gets good performance increase when the computers do not have to swap  Allows for load balancing and redundancy

PVM POVRAY  Problem  POVRAY brings in the whole image on each machine  Solution  Instead of using the PVM based software, rewrite the parallelization of POVRAY with MPI and use the algorithms used from prototyping to only bring in what is needed on each computer

In conclusion…  Few problems  Things went smoothly