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.
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
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
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
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
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
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
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