notes on scene 6

This whole endeavor has been an exercise in tradeoffs.

The shadows are generated with the simplest possible shadow map approach. No softness, and even the light angle is represented as just a skew, not even a full rotation. Used 4k x 4k shadow buffer. Tradeoffs! (Press 'a' key to see shadow depth map.) 

It is pretty glitchy, objects z-fighting with their own shadows sometimes, roundoff manifests as sawtooth effect, but it still does add a bit of depth to the scene overall. Still, I can see why many games opt for vague nearby darknesses, rather than optical shadows.

The shadow mapping error vaguely resembles light-wrap or a hint of subsurface scattering at times. (Lemonade.)

The light is gradiated from 1.0 at the center to 0.5 at the edge, again, adds a somewhat pleasing depth.

The zigarruts are artificially darkened on the in-steps, perhaps similar to an ambient occlusion effect. Perhaps. Their main purpose in the scene is to catch more interesting shadow shapes than the base plane.

The "maze" is built by putting down some connectors on the very-limited xyz grid points. A second pass looks for dead ends (nodes with 1 neighbor) and adds more connectors, breadthfirst, until there are no dead ends. This is paced out by the scene builder state machine so we can see it happening, somewhat. It's all random; in a world this small, closure is reached fairly rapidly. As the maze is grown, seed colors spread. This gives the track an illusion of consistency, perhaps suggestive of metro subway maps.

The scene is managed by OmScene. For this exercise, didn't want to use someone else's framework; wanted to handle each and every triangle. OmScene isn't a framework, though; it's just helpers. It does not abstract the WebGL API. Abstractions are good, but I'm not yet fluent enough in this domain to do it cleanly. You really have to do it once yourself; after that, you're in a good position to write one, or know the right questions to evaluate others'.

The movement is handled by "sprites". Each vertex has an attribute "spriteNumber", and a texture map is used to pass in coordinates for each sprite. These modify the vertex position. This allows a lot of movement without a lot of draw calls, and without even modifying the vertex data. That hit is replaced by construction and submission of a smallish texture (several hundred floats).

Concessions to User Experience: Not much! The up/down arrow tilt is smoothed. The board is set up sequentially, so you can have some (minimal) visibility of the maze-building process. The shadow angle keeps changing, just for fun. The tracks are not physically plausible, but the eye is placed, at least, to avoid intersecting the track.

Notes & Observations
* My code is a great mess! I'm lately pretty practiced at keeping server code neat and organized. This is truly a whole different inventory to keep track of.
* Lots of opportunities for helpful data types around angles, and shortest turns and so on
* Lots of opportunities for utilities around range conversion, easing in and out
* Possibly opportunity for highly, highly structured state machines. Code built with rigorous state machines could be dashboarded and logged quite nicely.