|
About My Summer I was lucky enough to participate in the 2007 Computer Science REU at UNC Charlotte. I had a wonderful time and learned a lot. To find out more just read through the rest of this page. My final presentation and a small video of some of what I did is at the bottom of the page. About My Mentor Pictures from REU Project description and journal entries Brief Description: VGIS (Virtual Geographic Information System) is a large, multifaceted project to allow navigation of and interaction with very large and high resolution, dynamically changing databases while retaining real-time display and interaction. The system allows users to navigate accurate geographies (less than 1 meter resolution in some cases) with sustained frame rates of 15-20 frames per second. For more information on VGIS and how it was previously used visit: http://www.dvg.uncc.edu/research/vgis.html Current Project: Integrating a two handed interface to work with 3d volumetric data in a stereoscopic environment. Journal Entries: 06/14/07 OK, let me catch you up, and then I can do this on a more per topic basis. First of all let me describe what I'm doing. I'm working with a software package called VGIS. It's basically Google Earth before Google Earth (or Keyhole) was invented. It has been used for many different research projects, so it has a lot of unused code in it and I just have to ignore most of it. Commenting is also horrible if it's even there. So... I'm having fun (not really) tracing down code. Working with VGIS is fun, just not the tracing down code part. The project I'm currently working on is working with a two handed interface and a stereoscopic (3d) display for viewing volumetric data, ie. 3d weather data and such. The two handed interface was not working correctly, and hasn't been apparently for the past three years, so that was the first thing I had to fix. Once that was done we ran into tracking issues. OK, to explain this, I need to explain how the tracker works. The way the two handed interface works is you hold two receivers with buttons and an emitter transmits a signal to them. Their location is determined by variations in that signal. But anyway, basically you have two 3d mice. The problem is that any metal near or around the emitter can interfere with the signal. In our building, or room at least, the floor and ceiling just happen to have a lot of metal in them. So..., we decided to lower the tracker some to try reducing the influence of the metal, and that seemed to work. Now I'm currently working on scaling and zooming issues. I'll post more details about that later though. 06/15/07 OK, We think we've worked out the zooming issues and we think the problem is more or less caused by the scaling class. So, now I get to figure out exactly what the scaling class is doing for the next few days. 06/15/07 Well, I've been trying to figure out the scaling issues and I just can't quite get it. So, I've been focusing my efforts on other matters. I've gotten the navigational mode switching mapped to a button on the two handed interface and I've been exploring the code trying to understand the scalecontrol class as well as working on this website. 6/23/07 A lot has happened since my last update. I've figured out the scaling issues, but let me start from the beginning. I was having trouble isolating what was actually scaling the view and where it was being called from. With lots of help from Dr. Wartell, I found out that the scale control class only sets the reachable distance and only sets that distance to whatever the function calling it specifies. So, we decided that the scaling being done by the fly navigation mode would suffice to do what we wanted. While I was working on figuring out how the fly navigational mode implemented it's scaling, I solved what I called the "growing box problem" and a few other things. The growing box problem was that the selection box being created to select 3d volumetric data would keep getting taller, or increasing in height, when selected for resizing. Anyway, so with lots more help, I isolated where it was calling the scaling function and set it to be called constantly. Then we ran into problems with the fly navigational controls running at the same time as the grabNDrag controls. So I had to hack in some if else statements and stuff to make them work exclusively while the scaling was still running. Now, that works, but we want more of a permanent solution by placing the scaling function into its own class. I've accomplished this with lots and lots of help again from Dr. Wartell. However, at the moment it does not fully work. Currently only grabNDrag is working, not the fly navigation mode. But that gives me something else to fix. 7/05/07 It's been a while since my last update, so here we go. Ok, I got Fly mode working properly again and it calls the Cyclopean Scale class correctly and everything. Now we decided to go back to the standard navigation mode, which is orbit mode. Things seemed to work fine at first, but then we found more issues. The code that scales in Orbit mode was conflicting with the scaling code in GrabNDrag. So, we had to make them work exclusively and there still seem to be some issues, but that's what we're trying to work out at the moment. 7/9/07 Well, since my last update. The issues that existed in the end of my last post were due to two conflicting functions running at the same time. Both were trying to scale the view and therefore causing some issues. I tried implementing a pointer based system to only cut one on when the other was not running and failed, however Dr. Wartell came to the rescue and fixed it. After we verified that it worked, I took and modified the Orbit.cpp class to have a externally accessible function to set whether the adjust_distance() function ran or not. We figured for future development, this is how it should be done so that other modules can provide their own scaling and allow them to cut off Orbit.cpp's. So, I got that working and now we are trying to focus on some precision issues with the cursors and the volume selection boxes. But for now I'm working on a presentation I have to give on a paper on tomorrow. 7/12/07 The precision issues with the cursors have been solved, well temporarily. We have to modularize what I did, but it proved that it does work so that we didn't have to go through all the trouble of modularizing and then it not work. So, with lots of explanation from Dr. Wartell, I found out that there are different coordinate systems within VGIS and when you extend one to far, it's precision gets lost and a more local coordinate system needs to be used. So for the case of the cursor we decided to use the Projection platform's coordinate system so that the cursors are always rendered relative to the platform, which is always close, and therefore always precise enough for the cursors. Next we have to see why the cursor disappears when getting closer to the earth and how to fix the volume selection box precision issues. 7/13/07 We decided that modularizing what we used to fix the cursors was a waste of time since it is really only an isolated case and will probably not be applied to any other situation and most cause more trouble by modularizing it. The front culling plane is what is cutting the cursors off and Dr. Wartell said just not to worry about that for now. So, the new goals are to do the following: Show which of the scaling algorithms, if any, are running. See if I can figure out why the volume within the selection box disappears when zooming in to it. Then also a sub goal is to try to figure out why the spheres on the corners of the selection boxes, which the user grabs to resize, are not being scaled properly. 7/17/07 Ok, I got the scaling algorithms being shown on VGIS's display, but that was easy. Now I'm working on finding where this volume disappearing problem is located. I've noticed that when the box is taller, longer, or both, than a certain size, the volume reappears. There are also two types of selection boxes. There is one to select reflectivity data, which is doplar radar data and one to select velocity data, which is basically the wind data in 3d. We typically use the reflectivity selection box, or rbox, because it's the first option when VGIS starts. But I decided to see if the same disappearing volume problem was occurring when we use the velocity selection box, vbox, and guess what? It doesn't. So, now I've just got to find where in the world the code that culls one and not the other is located. Another issue I saw when finding this, is that within the vbox selection, it is only supposed to show velocity data, at the moment, it is showing both. Well, at least that is my current impression of how the selection boxes are supposed to work. As far as the resizing spheres, I've gotten nowhere. I tried to simply modify their size, and all they did was disappear completely, so I'm putting that off until I get this volume disappearing issue fixed. 7/23/07 I found where the code that was making the volume data disappear! Well, it was actually in two places. Dr. Wartell found the first case, and I found the second. I just hate that it took me an entire week to track down both of these. Now, I don't know where we're headed. So, that's all for this post. 7/30/07 Well, this will most likely be my last post. I may put my final presentation and my abstract on here, but as far as posting updates to the project, this is probably it. My last goal is to functionalize GrabNDrag's box rotation and the actual GrabNDrag operation so that they both use the same function. After that, I'll be done with my part of this project for the summer and I don't know where they'll take it after this. There are many things that could be done, I just don't know what they will do.
|
