(Until there's a better name...)
Jeffrey Bergamini
Fall 2002 - Spring 2003
California Polytechnic State University

View of Half Dome from Virterrain



  • 5/18/03 -- Finished for now.

    I think I'm done with the project for now. Added cloudy sky background, seen above. Finished writing the report. That's it.

  • 5/6/03 -- Still Writing

    I'm still writing - slowly.

  • 3/17/03 -- Rushing

    Added support for automatic DOQQ download from CASIL. Seems to work OK. Also menus for opening/reloading recent files. Forgoing navigation buttons for now while I write the report. Mouse movement is probably more intuitive anyway. It needs a name, but I'm not going to worry about that for now. jbergami@calpoly.edu if you have any ideas.

  • 3/14/03 -- Finishing touches, I guess

    Getting closer to a finished program. The remaining details are mostly UI-related. As you can see, CSUN's map of quadrangles is now incorporated and you can bring up any DEM by clicking on the map. Need to add navigation buttons in addition to the mouse-based movement. Also (for the shaded/non-texture terrain) I'd like to add support for adjustable colors and lighting. I think I'll also add support for automatic image downloading from CASIL, even though the files are huge. Other than those things, it's pretty much done.

  • 2/26/03 -- Blending problems - Decision time

    The only difference between this shot and this one is that they were taken on two different computers. Both were running the same code on the same version of Java and Java3D with OpenGL. They are quite a bit different, and that's a problem. Last night I was able to get all 4 DOQQs mapped onto my quadrangle successfully, but it seems to work on some computers and not others. I think I know why: To get all four images to show up (not overlay each other with their stretched boundary pixels) I'm taking advantage of something called the texture boundary color. I can specify that when loading the texture, and I'm using the alpha channel of that boundary to make it completely transparent. That way, theoretically, none of the stretched borders should be visible since all texture coordinates are mapped into a non-border section, and the border sections are transparent. However, and I'm guessing this has to do with video card (alpha blending?) issues, this technique doesn't seem to work everywhere.

    To make matters worse: If I run the DirectX version of Java3D on the machine that still had boundary streaks overlaying the other three quarters, the four quarters display OK (and the renderer runs much faster), but the same image is in all four quarters. This happens with absolutely no changes to my code.

    I have to make some decisions about whether to scrap this and just show one quarter quadrangle at a time or try and fix it the way it is.

  • 2/09/03 -- Some texture

    This shot shows texture mapping in action. It's not quite aligned yet, and I had to manually lower the image's resolution to get Java to handle it without exceptions, but the basic functionality is there. The images available online are DOQQs (digital orthophoto quarter quadrangles) so in order to cover an entire 7.5" quadrangle I'll need to coordinate 4 textures onto the same shape. I think I can use texture layers for that, as long as memory requirements aren't too bad. I wonder why Java won't process a high resolution image (these are coming at about 7000x7000 pixels), and will try to figure out how to get around that. It would be nice to use the full 1-meter resolution.

    Also, shading won't work yet on the texture. I'm trying to figure out why.

  • 1/20/03 -- A couple more screenshots to illustrate news

    First, real vs. virtual views of town from the top of Bishop Peak prove that these models do actually seem to match the real places.

    Also, the "triangular grid" look is now gone due to smoothing, which I may or may not maintain. It does look good though, much more like the NASA picture up there.

  • 1/14/03 -- Proportional

    Proportions should be ok now. Take a look. These 30-meter resolution DEMs will obviously not have detail fine enough to display scenes exactly like the one from NASA above, but hopefully they will still be ok. I'm still considering some smoothing / interpolation as well.

    Generating surface normals for a terrain made from an entire 3-meter resolution DEM looks impossible (and subsampling would kind of defeat the purpose), so I'm leaving that out of the picture for the moment. Why? Normal generation takes more memory than the maximum heap size I can give to the JVM, which right now is about 1.9GB.

    I've got my fingers crossed at this point that mapping the 100MB+ TIFFs that I'll be using for textures won't bring Java and/or my video card to their respective knees. This week I invested in another 512MB of RAM to make this stuff easier to run. Throwing money at the problem.
  • 1/1/03 -- Normals

    Surface normals look right, so the terrain is rendered with filled polygons now. Proportions are still screwy due to fitting the whole scene into a cube. That's the top priority for now. Running the demo takes up to ~210MB of memory at some points. I think there's not much helping this due to surface normal calculation on a geometry array consisting of around 175,000 vertices, but it's still annoying. Will look into that eventually.

  • 12/28/02 -- 3D Model

    Preliminary 3D model is working (point-rendering only) -- screenshot

Minor Documents


Implementation directory contains:


Jeffrey Bergamini (jbergami@calpoly.edu)