About three weeks have passed since the last update, here’s a quick brain dump of some of what I’ve been working on:

GLGeom

Inspired by the OpenGL Mathematics (GLM) library, I decided to factor out the lxcore “graphics math” code.  The factored out code fell into two buckets: code that can be replaced by GLM and code that has been moved into GLGeom, a new library I’ve added to the LxEngine codebase that builds functionality on top of GLM.   GLM contains a lot of useful base functionality for manipulating vectors, matrices, and quaternions – and at multiple precisions.

GLGeom builts on GLM and tries – for the most part – to follow its conventions.  Here’s some of what it adds:

• point and vector specializations of glm::vec (i.e. strict typing to differentiate a point from a directed length)
• color specialization
• radian and degree specializations (i.e. strict typing to avoid simple mismatch unit errors)
• ray, line segment, line, curve primitives
• plane, sphere, cone primitives
• bounding box, bounding sphere primitives
• intersection functions

Again, the intention is to be completely inter-operable with (i.e. complement, not replace) the OpenGL Mathematics library.

In addition to utilizing the excellent work done in GLM, the construction of GLGeom was also motivated to slice off a smaller piece of the very ambitious LxEngine project; within that smaller project, a higher degree of quality is likely achievable in a shorter amount of time (completeness, documentation, testing, benchmarking, etc.).  Having a “showcase” smaller sub-project like should help define what strategies work best for development.  What works there can then be transferred over to the larger LxEngine project as a whole.

To Be Precise

A small, tangential comment in relation to GLGeom: I’ve posted on precision before, but in setting up the initial benchmarks and unit tests for GLGeom, I was once again surprised at the limits of precision in floating-point arithmetic.  In simple ray-sphere intersection tests, it’s quickly evident how much loss of accuracy can occur in a series operations on mixed large and small floats.  It immediately made me want to dig into possible fixed point math experiments and large-scene spatial indexing techniques to boost precision without having to just to double-precision math (and storage).

If I reached any other conclusion, it would be defining a precision goal for LxEngine: any object that can be contained within a cubic kilometer should have intersection accuracy up to the nearest millimeter.  Eventually, spatial indexing should allow for sub-spaces such that the units themselves do not matter, but rather the generalized goal of  accuracy to 1 part in 1,000,000.

Ruby on Rails

Though not directly related to LxEngine, I’ve also been experimenting with Ruby on Rails.  I know very little about either so this is a good look at a “new to me” technology to keep my mind open to alternate approaches to problem solving.

The biggest idea sticking with me thus far is the “coding by convention” concept of Rails: basically having a large set of logical assumptions (enforced by convention) about how things fit together rather than manually configuring all the wiring between parts of the application.

This is not something I knew there was an explicit term for, however it has always been a goal of LxEngine.  It should just work out of the box.  Support incremental, live development – no need to code from scratch.  Provide logical stub functionality.  Be user-friendly to the developer as well as the user.  Etc.

General Thoughts on Goals for LxEngine

• Exact, testable guarantees on precision (i.e. accurate to the millimeter on objects that span no more than one cubic kilometer)
• MVC mode, similar to Ruby on Rails
• Coding by Convention, similar to Ruby on Rails
• Incremental, not from-scratch development
• Start with a working application
• Live testing, developer-friendly mode (auto-reload scripts, plug-ins, etc.)
• Instructive defaults (i.e. stubs rather than failures)
• Write it once: no duplication between dependencies
• Unit test everything
• Automated benchmarks
• Domain Specific Languages
• Transaction based, with revision history
• Clear demarcation between persistent and transient operations
• Core, Extension, Prototype, Utility sub-sections of each library
• Data source abstraction / transparent serialization
• Person friendly development (e.g. use names, not UUIDs)
• Procedural generation at system limits (e.g. new content rather than boundaries)
• Development time is more important than run-time