For those of you following my project, two weeks ago I experienced a devastating setback. I was working on a ray-picking function to enable a finer degree of interactivity with my planetary model when I hit a point where I wanted to stop, and in turning to my task list, found that I had run out of material to adapt.

I did the natural thing at that point and began looking for ways to expand my model and continue where the material left off. And that was when I realized that without significant research into the math and science underlying the models, I couldn’t continue. I’m a hobbyist, not a geophysicist.

It uh, hurt. I don’t know how often other people deal with this, but for me personally, it was yet another confrontation with the limitations of my understanding of math and science. I could comprehend them just well enough to translate functions written in C++ to Java, but not enough to write them from scratch.

It’s humbling and like I said, it hurt. I took a hard look at what I had done up to that point, which I should have had every reason to be proud of, and tried to figure out what to do next. It took a day or two to recover enough to get restarted, but I think by the weekend I was “working” again.

My current plan is now translating a couple of JavaScript planetary simulations to Java. It gives me an opportunity to study some JavaScript and practice converting more “functional,” interpreted code to static, compiled code. I’ve already encountered some interesting “quirks” of the language.

After a few hours working on the new project’s geometry procedure, I had figured out enough of what was going on to realize what I already had was better – I mean, I can’t speak to what it would be like running out of a browser, but it runs cleaner and doesn’t produce lots of out-of-bounds exceptions like the JS code apparently did. Honestly, after a couple hours chasing the problem on forums, it’s hard to figure out just HOW MUCH exception-handling gets swept under the rug by the interpreter.

So, I started in on transferring and refactoring my original geometry code from working through my previous project. I cleaned up a lot of stuff, added better comments, and finally created my own “Vector3” object to make my float arrays more readable (and bake-in some FloatUtil and VectorUtil functionality from JOGL). In fact, a lot of the refactoring has been wrapping JOGL utils and adding them to my classes.

Now that I have a bit of experience with JOGL, I’m looking forward to how I can streamline some of my code by pushing it through functions that I have more experience reading and using — as opposed to say, trying to decipher long, chained functions whose operations I barely understand. I’ve also taken steps to make the geometry code more portable if (I should say “when”) I need to move it to a new project.

About the middle of last week, I reached a point where I could display the basic geometry created by my new project. I was able to copy-paste a lot of code to the new project, owing to the successful decoupling of a handful of dependencies and the abstraction of objects and methods.

I’m doing better with a set of tasks ahead of me to keep me focused and busy. There are dozens of to-do’s that will have to wait yet another iteration of the world generator before I can begin implementing them, but I like to think I’m a bit wiser and a better programmer since I started this version.