Components entities properties and heightmaps..

Currently I am in process of creating Component/Entity based architecture, more precisely, a pure component model based architecture, with sugar coating on top.


Sugar coating goes as far as to creating classes, that inherit from Entity, and the functions being just wrappers, that call different properties, set them, initialize them, create them. 
What has gotten me worried lately, is the granularity of the properties; at the moment I have the location properties, scenegraph properties, text properties, name properties as separate things, this could cause locality proplems.. One thing would be to combine LocationProperty and SceneGraphProperty, and pack the data tightly, hopefully increasing locality.
But on the other hand, this sounds like premature optimization, if needed, I can merge properties later on, creating SceneLocationProperty.


Well anyways, I removed the depthbuffer problem..

Another thing that I am pondering about is the landscape rendering, how to do a heightmap rendering? I thought of loading data from images, but that is too limited, having only 8 bits per vertex for height just doesn't cut it. Next I went and thought of loading obj files packed in gzip files and using somesort of quad-tree to organize different pieces of the map together. But this too is a bit of limited. My current idea is saving n obj files logically, in a tiled pattern to disk. mapname_LEVEL_X_Y_Z.obj where LEVEL is the 'level of detail' level and X,Y,Z are the indexes of the tiles, LEVEL 0 tile size would be 10meters*10meters*10meters and if such file was not found, then that level of LOD is not supported. The LEVEL LOD works using n^2, so that level 0 is 10m, 1 is 20m, 2 is 40m, 3 is 80m .. etc.

For test purposes, I will first implement this using obj files, later on, when I see some results, I might create either my own filetype for the data, or use some, more sophisticated format, than obj.

The third thing that I wanted to share, was these few C++ patterns, that I've started using, quite a lot..

First, the templated Singleton, with this the classes do not need to specify a singleton inside the class (reinventing globals! :D.. with sugarcoating.). 

Second pattern is the Merge class, that can be used to merge, through multiple inheritance, two classes into one. The verdict, whether this is good idea, is still out, but I like a lot about the idea of having the ability to merge std::mutex with whatever the mutex is meant to lock. eg. Merge< std::vector<int> , std::mutex > myVector; and locking the vector by std::mutexlocker lock(myVector); , this way I use it in the Pipeline.