For the last five or six days I’ve been working very diligently to build a simple 3D isometric terrain rendering engine using JavaMonkeyEngine 3 (JME3). I was delighted when, by the end of the first night I had assembled the necessary geometries for my surface tiles and textured them. By the end of the second night I’d forced the camera into a parallel projection mode and positioned the scene with respect to the camera so that everything was rendered at the requisite angle.
From this point on, all I really need is to light the scene. However, this disarmingly simple thing has turned into a frustrating and heart-wrenching struggle. I have to conclude, after several days of hammering, chiseling, scraping, poring through source code, online tutorials, and relevant books on the subject, that JME3 is not going to work for my project.
After several confusing false starts, I decided to simplify the lighting problem. I ditched my complex models and implemented a Mesh that is, functionally, half of a cube. Just the 3 quads that face the camera. I computed the surface normals for these quads (this is very simple, because the object is a cube, and it is aligned to the X,Y, and Z axes), and then set up three directional spotlights. One red, one green, and one blue. The goal of my experiment was to shine each of these lights on a different face of the mesh. For comparison, I included a com.jme3.scene.shape.Box in the same node as my mesh.
One of the first things that I noticed was that the Box model had to be rotated slightly in order for its normal vectors to align properly—in other words, shining a light straight down from above (0,1,0) lit one of the back-facing quads on the cube. That was straightforward to resolve by rotating the cube. Still, as the days marched on, no combination of effort and experimentation would result in the effect that I was attempting to produce, which was a light shining down on the tile nearly vertically, while lighting the two vertical faces of the tile at noticeably different degrees. Eventually, I realized that even if I did manage to tweak and torque the normals around and the lights to get the effect I was after, it would almost certainly break or behave counterintuitively once I began to vary the angle of the top of my tiles, which is the whole point of this work.
I’ve decided to give up JME and work more directly with the Lightweight Java Games Library (LWJGL). I don’t need physics, collision detection, particle systems from a massive game engine. I just need rendering. Triangles, textures, and light. Still, it’s a big surprise, to come so frustratingly close to completion only to turn away from an otherwise excellent library.
I spent a few days this week dusting off old software projects and touching my roots, as it were. It’s interesting to go back and see the work that I was doing before I started graduate school, with a radically different perspective.
One of the projects I’m most proud of is CORM, a commercial object-relational model that essentially implemented the enterprise archetype patterns of Arlow and Neustadt in Java. These simple, object oriented representations of business relationships were designed foremost for persistence, and I can really see where the JPA and persistence properties of the external environment influenced the design of the software, particularly with respect to the quantity archetype patterns. But one of the archetype patterns, specifically the one that pertains to “quantity”, eluded me before graduate school. Partially because of limitations in JPA, partially because of limitations in the Java language, but also partially because of problems in the science of measurement itself.
Here’s the thing-the foundations of the science of measurement are themselves in flux right now, as the scientific community works on standardizing and formalizing systems of measurement. Sure, quantitative properties like “length” are pretty well understood. We learn about length and mass and so on when we’re children. But, it’s also well known that the length of metal rods can be affected by their temperature. So, when you record the length of an iron beam, do you also record the current temperature? If not, then it becomes a hidden variable. If so, then you must codify temperature as an affecting quantity of length with respect to metallic objects for the sake of measurement. Even then, certainty and precision in measurements are also major contributing factors to accuracy and error for purposes of analysis, but there are not presently (that this author knows of) excellent standards for defining and recording these characteristics.
So, the science of measure is a little bit up in the air right now. Building software to create formal models of these types of systems is made somewhat more challenging and interesting by limitations in our current epistemologies of measurement. For a system of data objects to be implemented correctly, it must lend itself to dimensional analysis, fixed and contextually relative conversions, and be open ended enough to accommodate new types of scientific models such as those employed in economics and the social sciences. Right now, no single school of thought captures all of the various subtleties needed to do so.
A well-written piece of software might actually help to clarify and formalize some of these relationships and definitions, bringing in concepts and principles from information theory, and isn’t that a tasty dish to serve posterity?
This is just one more way in which the Internet remains a vast and untamed frontier.