As development of the basic engine API is coming to an end, I will be opening alpha testing starting June 8th 2012. It has been a long and difficult journey to produce the API, and, while it may not win any awards, I am proud to present an engine that employs technology that even professional engines do not, and will not be able to offer.
Summary:
So far, the engine is mildly stable. There are no known memory leaks and API calls and errors are greeted by error messages or fixes rather than crashes. Memory use is not yet fully optimized but it is already better than my original target. CPU and GPU usage remain an issue, mainly due to the crude culling and collection of geometry. Currently the engine can render nearly 1 million polygons on my 16-core Nvidia 9400m graphics chip and mobile core 2 quad with frame rate upwards of 30 fps. Not too bad in my honest opinion, that’s also considering that the said condition consisted of 5,000 unique objects in the scene.
Set backs:
I had recently completed an extremely successful Loose Quad-tree culling system. Unfortunately, Visual studio debugger decided to screw me over and somehow managed to erase my source code and the object file (so no chance of recovery) and binaries. I don’t have time this week to re-implement this so it will have to be moved back.
Success:
After a few talks with my friend over at Overkill (http://www.overkillsoftware.com/), I decided to cut a bit of object-oriented design from the project and completely overhaul the mesh and object classes and adapters. CPU usage is now down over 70% while memory usage is down just under 40% (GPU performance remains more or less the same). I have also started coding some useful rendering abstractions. Binding constant buffers/variables and other resources to shaders is now extremely simple and one API call will handle the implementation across various platforms. I have done similar higher-level functionality such as a blazing fast text, GUI, and sprite rendering system and game object system. You can now also run the engine on DX10.0 level hardware as I rewrote the standard shaders and features to work with both dx10 and 11 features.
Future:
Besides re-programming the advanced culling system, not much remains to be done (at least not on the low level). The lighting pipeline needs to be coded (I already have an entire API so it should literally only take a dozen lines of code and a few HLSL files copied from the prototype) and I need to implement hardware skinning, physics, and ray tracing.
If you are interested in evaluating the engine during the alpha release please send me an email for consideration. If you have any questions feel free to comment below or send me an email!
-Michael Auerbach-
texcoord3 
This is a really interesting engine you are working on. Are you planning to implement support for hardware hull and domain shaders? I’m actually working on a project within Cryengine 3 but am looking to shift it over to an independent engine. I’d certainly be interested in alpha testing this when you reach that stage.
The short answer is that the engine API already supports hull and domain shaders and has a few built in functions to facilitate constructing pipelines and shading chains. The engine API does NOT have these convenience functions for compute shaders yet but this is a critical element that I will be adding when I get more time (this summer).
The engine was designed to meet my own needs and as such is ideal for developing and prototyping new rendering and graphics algorithms quickly while not sacrificing performance. For example, if you wish, you can write the HLSL files of your custom rendering pipeline and very easily load, “link”, and execute them. The API abstracts things like mesh loading and processing, culling, device state changes, managing and executing the rendering pipeline, and updating and sending resources to the GPU registers and main memory. However, you still have the ability to directly query almost every low level device used very efficiently in the current build which makes the API ideal for both novice game/engine developers as well as advanced users who may want to go as far as to re-write my code for their own specific needs (although it is already extremely versatile).
If you just want to render everything in the default pipeline but change the hull and domain shaders for say rendering the g-buffer and/or shadow maps, you’d literally only have to write/modify the HLSL files, and change or add a single line of code in c++ and it will work* (if you need new parameters passed in to the new DS/HS you might need to modify the VS as well).
I’m mainly using the Hull and Domain shaders for hardware tessellation. If there is already built in support for that, then the default pipeline should be fine.
by default the engine expects art assets (3d models) to come paired with diffuse, material, and height/bump maps. Detail displacement mapping is applied to all object/surfaces that have an attached height map automatically when the object is within a certain adjustable LOD threshold. Note that some things like terrain, grass, and foliage use a different default tessellation scheme. You can also set tessellation style per object or per-face: PN-triangles, sinc-weighted tessellation (smooth surfaces), displacement mapping, none. Those are the default tessellation patterns you can set.
Note that authoring tessellation-ready art can be extremely difficult and time consuming – hence the low level of adoption in the industry. While the engine can attempt to fix some seams, you will always have to be very careful about each vertex’s normals and UV values. UV/Normal discontinuities may cause seams when displacement mapping is applied.