Most engines on the market have their drawbacks and it's difficult to find a simple/light-weight one that's open-source and doesn't have to put you through a rather complex learning process. Writing one is a difficult task on its own, but it might not be a bad idea if what you want that engine to do is to support a specific kind of games (e.g. 2.5 D games on mobile devices).
So, in search for a good game engine architecture, I've found a few logistical issues. Consider this scenario:
Each object is comprised of two principle structures of render information:
- a model (geometry mainly) and
- a material (that tells the object what textures and what shaders to use).
Of course, it is natural to allow an object to switch its material definition on the fly. But a material encapsulates the shaders, so these drag along with them some slots for uniforms and vertex attributes.
Since an uniform, for example, can be:
- object specific (color, specular exponent, etc.)
- global/superglobal (lights, weather conditions/fog/wind,etc.) or
- specific to a group of objects (they all have, let's say, a reflectivity factor)
then it means that it's wrong to put them in either the object's property region or in the material's property region. It's clear that both uniforms and attributes are always declared in the shader sections of a material, but where their values come from is an enigma in the frames of a pretty general rendering engine. You have to allow for the existence of numerous types (by semnatics!) of uniforms: position, colour, bone matrices, indices, lighting parameters, etc.
The big question now: how would you suggest to organize and manage uniforms? (especially the information flow - they're declared by shaders, but their values are supplied by apparently different type of entities - some renderable, some more abstract, being themselves controllers or managers).