Texture Mapping

The texture mapper for the most part is complete. Here's a screenshot of it being started. When the command "tex" is entered, the screen changes perspective to make room for the texture and any accompanying data. The example texture here is called "desertcamo.bmp" and is loaded with the "loadtex" command.

Mapping the texture is fairly simple--first, select an object, then select a face to map to, then switch to point mode. Point mode then enables you to give each vertex a coordinate relative to the texture. To load the coordinate into the vertex, simply click somewhere on the textured square.

Here you'll see some faces have been textured already. One of the features of the mapper is the ability to mark a face to see what points have been chosen. This, coupled with a crosshair allows a user to finetune where texture coordinates will end up relative to other faces. In the picture, the current mapped face is shown as a light blue wire triangle. The other marked faces are shown in dark blue. On the model itself, the current selected face is shown as a dark red outline if it's marked, and bright green if not (not shown here). Points on the face are shown as small white cubes normally, and are slightly larger light blue cubes if the point is currently selected.

Any additional data about mapping is shown via textual information a third of the way from the bottom of the screen.

This project is almost done. All that is left is to sort out some easily-fixable segmentation faults (unassigned pointers, etc.), setting up the opening/saving commands to include texmap data, adding support for more than one texture on a model, and tweaking some of the functionality and features. Depending on whether I get a wild hair and make something totally different on here, this will be the last update before I release this program as open source.

Texture Mapping

A texture mapping mode has been implemented. I plan on using mouse listeners to determine where on the texture the mouse has been clicked and translate that into texture coordinates.

The cross-shaped model shown is a base for what will eventually be some kind of anti-aircraft gun.

Home Stretch

I wanted to get a bunch done before reporting on here.
Rotate and translate sub-objects: The modeler can now update where the points of a sub-object would be after either of these transformations take place.

Relative and Absolute Move: Relative move is for butting a point from the target object to a point on a destination object. Absolute move is for relocating the actual center of the selected sub-object.

Stray Points: These are used for reference when drawing new faces or moving things around. The white dot by the red axis is a stray point.

Stray Faces: These are separate custom faces used when primitives just don't do the trick.

Right now it's just a matter of wrapping up the rest of the functions to be implemented and fixing some buggy code. There will be a texture mapper implemented later on to flesh out the models and give them some flavor.

Resume

Texture Mapping >>>

Rotation and Point Mode

Rotation is finally done. This enables a user to rotate an object about the x, y or z axis and update the point locations in real-time. I needed a way to remember the locations so they could be saved to a text file when editing was complete.

The renormalization process is a little flaky. The smooth normals should only be assigned 1 per vertex and they're showing up in pairs, which cuts down on the overall smoothness of the model. It's hardly noticable, but it's a problem that should be addressed.

Future optimizations will be to place the current rotation angles in the object structure itself, and allowing OpenGL rotate the object on screen with its own rotation functions. Only when the object(s) is/are saved will the hard-coded point manipulations take place.

Also, point mode was added, which permits the addition of "stray points". These stray points will be used by themselves or in conjunction with current vertices to generate new faces.

Resume

The Home Stretch >>>

Smooth Shading

I realized that making objects out of a million faces wasn't working. This is an example of smooth shading by changing the normals for each vertex in the mesh.

The old way was to set each vertex on a face to be the same normal which resulted in blocky lighting effects.

The new way is to calculate a new normal based on the old normals from adjacent faces. There are a couple loops in place that go through the list of faces, check every point to see if a particular point is shared by another face, and used the shared-face's normal to change the resultant smooth-shader normal.

The torus you see here is made of 400 faces--it's the lowrez version from the last entry.

Resume

Rotation and Point Mode >>>

Normals

Normals are pieces of information that OpenGL uses to govern what shade of a working color to apply to a given face. It determines this based on where the light source is, and the more the normal points towards the light source, the closer the face color is to white. With a large amount of normals and faces, it's possible to make an object look smooth from a distance while it's still made of many flat faces.

Also, a wireframe mode was implemented, which is crucial to view the skeleton of the model. Object selection is still in place, along with two new modes--face- and point-selection. Face selection will be for creating and editing the properties of individual faces, while point selection is for moving a particular point (and all other points with that same set of coordinates) wherever the user desires.


You can see the normals being viewed in the picture to the right. All normals are shown as short blue lines. Normals on the selected face are longer and light blue. This function was implemented because the formula for generating the normal occasionally generates an entire map of normals that face the wrong way, and it's meant to be a "finishing touch" of the final program.


This is a screenshot with 3 types of torus resolutions. I picked the torus since it requires the most complex calculation to determine face locations. It took about 10 seconds just to start the application.

Floating point variables can be caught and used now, so face creation and editing is imminent. This would allow a user to create new faces from scratch, built from vertices already in place from primitives.

Resume

Smooth Shading >>>

Resume

Michael G. Fritzius
3440-D Evergreen Lane; St. Louis, MO 63125
Cell: (636) 692-1426
code_monkey@slashmail.org

Work History:
Control MicroSystems
405 Main Street--Fenton, MO 63026
October 2006 to Present

Full time employment--Lead programmer for embedded projects (microchips) covering a wide array of applications: stationary and handheld wastewater treatment modules, fuel sensors and cellular modem transmitters. Also created joint applications that interface microchips with computers for fast data transfers to free up resources from the device level. Programming languages used were:
· C for all embedded development (microchip-level programming)
· Java for some graphic interfaces concerning fuel level sensors
· C# for all graphic interfaces and front-end/back-end applications for customers

Schnucks Supermarkets
1393 Big Bend Road--Suite 1--Ballwin, MO 63021
October 2001 to April 2008

Part time employment—Customer Service, catering, face-to-face and over-the-phone customer interaction, various maintenance duties.

LMC Industries
100 Manufacturers Drive—Tenbrook Industrial Park
Arnold, MO 63010
About May 2001 to July 2001

Full time employment—operation of metal stamping die machines, performed quality testing of parts, tolerance and breakage analysis and occasional maintenance of the machines.

Computer Skills: Experienced computer assembly (10+ years), Programming (5+ years), Knowledgeable in C, C++, .NET, OpenGL, C# and Java, Network Programming, SMTP and POP3 Mail operation, Hardware-to-PC Interface for Data Analysis

Other Skills: Graphics/General Application Programming (DOS), Technical Writing, Customer Management Skills, Electronics Assembly and Soldering

Current Projects:
A miniature version of AutoCAD that will be used in upcoming game projects whose goal is to facilitate the creation of 3D objects and models. The entire project is currently written in OpenGL based in C++. This program handles texturing/skinning operations, “smoothing” algorithms, allows the user complete control over model viewing, and will evolve to handle model animation. The final release will be open source and will be ported to C# for ease of use. An overview can be found at: http://www.minicad-michael.blogspot.com/

An aftermarket field camera modification for hunters that can transmit its payload of pictures to an email address, whose processor is loaded with code written in C. This device “piggybacks” on the camera and controls access to an SD card while the camera is in an idle state. Information is retrieved from the SD card by using the FAT16 file system. The device then initiates an internet connection via a cellular modem. Emails can then be sent to any destination using the SMTP protocol, which includes the desired picture encoded in the attachment section of the email per RFC 822 protocol. The end result is an email sent to the customer containing the most recent picture.

Past Successes: Designed software for a car seat “reminder” that plays music when a child is occupying the seat and the car hasn’t moved for a short time. The device senses movement with the use of a small digital accelerometer, and can discriminate between vehicle movement and the child jumping in the seat. This project was taken on in response to summertime fatalities of children being left in vehicles. This project was also a finalist entry in the JPMA Awards in Late Summer 2008. Information regarding this project can be found at www.carseatmonitor.com. Code for the device itself was written in C, with some analysis software being written in C#.

Developed software for devices used in storm water monitoring systems. These devices detect the amount of particulate matter in runoff, and alert the customer to send a clean-up team. This solution was put in place to save money--instead of sending a clean-up team at scheduled intervals, they can be sent when needed. The information is sent from the remote devices through a cellular modem in SMS (text message) format to a main email address. A GUI (written in C#) then intercepts and processes these messages and sends alerts depending on what information has been received. Currently, both the remote devices and the GUI are under testing and it is foreseen that up to 1,000 units are to be sold annually. These devices feature code written in C.

Designed and tested a handheld sludge detector for use in sewage treatment plants. The sludge must be monitored regularly to ensure that a backup does not occur. This device is meant to replace the clear core-sampler tubes, which are used to measure where the sludge blanket is by pulling up a vertical cylindrical sample of the fluid in the treatment tank. These tubes are not only unwieldy (being up to 16 feet long), but also become brittle with use and can snap in the wintertime--so a different solution was presented. The handheld unit is portable and battery powered and uses an infrared emitter-receiver pair, along with a pressure sensor, to determine at what depth the sludge blanket is located. The code for these pieces was also written in C.

Created and tested a wide variety of device-to-PC GUIs for use in data processing--the most recent being used for the car seat reminder described above. The basic design of these GUIs is two-pronged: the first phase is devoted to collecting raw data, while the second is a “playback” mode, showing the data on-screen as if it were real time, making debugging and algorithms much more efficient. All of these programs were created using C#, and were central to the final stages of device development.

Programmed a passive fuel level sensor for Chrysler Corporation to replace the classic “floating ball” mechanical version. Also modified a previously designed GUI written in Java that interfaced the sensor with a PC to provide examination of operation of the sensor, which made it possible to come up with a better decision algorithm. The sensor has built-in “slosh detection” to prevent false decisions due to moving fuel. Also tested in a variety of temperatures to make sure the sensor would operate normally under all conditions. The code for these sensors was written in C.

Designed software in C# for a multiple solenoid timer tester (up to ten timers simultaneously) that communicates with a PC via RS232 cable. The software receives information from a testing board and determines if the timers are switching on and off at the appropriate times. It allows a user to pick a tolerance of values around the target times for each event.

Education: University of Missouri—St. Louis Bachelor of Science, May 2006, Computer Science—Minor in Philosophy, Mathematics

Jefferson College—Hillsboro Electronics Certificate, A.A.S. Industrial Automation, May 2003

Ellipsoids Work

Ellipsoids were finished up early this morning. The shape of the object is governed by 3 floating point values which denote its radius along the x, y and z axes. If the values are the same, it results in a sphere. If two are the same it forms a mashed/elongated sphere (spheroid), and if all three are different it makes an ellipsoid which is egg-shaped.

Note that one of the objects is yellow--the reason for this is because a function was implemented to select an object via right-clicking and dragging it around to rotate it about the x and y axes. Something similar will be in the final release, since an "object" will be made of many sub-objects.

Currently, I'm working in conjunction with a friend to determine where the points of a primitive object would be after all rotations are done. This way the object can be drawn in the correct orientation without wasting valuable rendering time rotating all sub-objects. A complete object will be treated just as a pile of polygons so the rendering engine can run through the list seamlessly.

Resume

Normals >>>