From patrick on Slack:
Figure out some major architectural ideas. Probably won’t get to the UI framework and 3D overlap/collision bit. I think once the 2D arcade overlap/collision is dialed in and the “modern” lighting pipeline is finished I’ll be ready to get back to the web portal and push out a beta.
Was hoping late March, but will probably be April.
Interested in early feedback on the new lighting architecture. It is incomplete, but if you look at the feature/dynamic-lighting branch you can see where things are headed. Basic idea is that in addition to being able to bind regular shader uniforms you’ll be able to specify semantically bound “pipeline globals” that will cascade down the layer/prop/deck hierarchy and will get plugged into you shaders for you. So you could defined a light type with a pattern of uniforms, assign it a “name” and then define at the shader level how it maps into your uniforms.
The missing pieces are a light list (in addition to the pipeline globals) and a prop/deck level “technique” that can sort and consume lights. So you can define your global lights then use one of the overlap/collision mechanisms of your choice to accumulate addition lights that will get consumed by your technique specification for 1 through N passes. i.e. “light this prop with shader X that needs Y global lights plus N lights from a list, then follow on with Z extra passes until some number of lights have been processed."
So if you’re doing a simple 2D rendering process you won’t pay for any extra overhead, but if you have a fancier model of, say, a character wandering through an environment with localized torch lights you can still handle that efficiently through Moai's retained mode.
The light model can specify both uniforms and textures, so you can do your shadow maps, reflections maps, etc.
This is all in addition to increased support for immediate mode rendering, so if you want to roll your own you can use Moai draw to get full access to the render state in addition to (or instead).
The other incoming feature for 2.0 is an arcade-style collision/overlap system that will be simpler to use than Box2D (or Bullet) for Nintendo-style action/adventure and platform games. Thought long and hard about this one and have been using Box2D for years as a reason not to do it. But if ou don’t need a centers of mass, etc. and just want an efficient way to create characters that do things like hug the terrain it’s very easy to set up.
Importantly, that will dovetail with the grid system so you can plug your collision edges into a big tile map and it works out of the box with instanced collision geometry.
Material system in 2.0 is now a first class citizen. The “inverse” cascade works the same - higher levels like layer and prop will override lower levers. So you can easily set up a pass (though a layer) to just do lighting (with its own set of shaders/materials) or force a complete override (to do a depth-only render or visor effects like the x-ray or heat vision from Metroid Prime).
Oh yeah, we’ll have a better spatial culling structure for 3D. Cells and portals, but dynamically resolved. Think CSG AABBs you can just drop over your geometry that will work with the camera to cull it for you. So you don’t have to do a bunch of pre-organization. Just drop in your cell AABBs and go.
Also adding bindings for Google VR and ARToolkit.
I realize that sounds like a lot of changes, but I’ve been happy with how low impact the refactor has been to the basic Moai idioms. I’ve renamed some stuff to clarify (for example, MOAILayer is now MOAIPartitionLayer to clarify that it has a built-in partition; as you might know, it always has). All these features will be opt-in. Performance and use otherwise matches pre-2.0.
And there will be an expanded animation rig that supports mixing. So you can still use your anim curves to drive attributes, or MOAIAnim to map a set of curves with a timer. There will be a MOAIAnimMixer object that adds one more layer, but will make it easier to schedule sets of animation.
If you’ve been following, you’ll have noticed a skinned skeletal animation demo. The anim mixer is just intended to make all that a little more manageable.
Ironically, a lot of these ideas were in the original pre-moai engine circa 2007, which was basically a Maya scene graph simulator. I’m finally at the point where I can bring these back in without losing the immediacy and configurability of Moai 1.0. Sorry, I meant feature/dynamic-rendering.
While the dynamic lighting system will bring a lot more power, we’re still missing a shader composition system. That is on my radar, but my thought is that it is solvable through Lua and tooling for now, since it’s mainly about preprocessing the shader scripts themselves. May never need an “official” system for that since Lua makes it easy.