Overview
L. Spiro Engine at the time of this writing supports DirectX 9, DirectX 10, DirectX 11, and OpenGL. OpenGL ES and the Nintendo Wii and PlayStation API’s will be supported. It uses Phong (per-pixel) shading rather than Gouraud (per-vertex) shading and is entirely shader-based (necessary for DirectX 10 and DirectX 11).
The shader language I am using is called L. Spiro Shader Language. It is a language I have invented in order to guarantee support for all platforms I wish to target (which are numerous). It is similar to HLSL and Cg, but borrows from GLSL a bit. After you write your shader in L. Spiro Shader Language, it will be correctly converted to HLSL, GLSL, Cg, or the Nintendo Wii “shader” model. Cg unfortunately does not support all of the platforms I wish to support, so making a new language is best. There are numerous semantics which are set and updated by the engine automatically so you don’t have to manually update them when you apply your custom shaders. Geometry and compute shaders will be supported but with a warning indicating that these shaders will not be activated/used in DirectX 9 and OpenGL.
Here are sample results from the early stages of the graphics library:
This model has ~250,000 triangles. There are two active directional lights. Diffuse, specular, ambient, and emissive material properties are all handled correctly and on a per-pixel basis, and hemisphere lighting is used for the ambient light (it is what is causing the bottom of the car to look green, as if it were sitting over grass). On my home computer this runs at ~2,200 frames-per-second. The engine is so new that I do not even yet have texture support, so textures are missing here.
Considerations
Many game engines start at high performance with few objects on the screen and rapidly drop in performance as the object/vertex count increases. In my engine, the initial performance with a few objects on the screen will be lower, but each additional object has almost no impact on the performance. This is how CryEngine 2 and above works, which is why they can have so many lush jungles and detailed scenes.
The first reason is due to Phong (per-pixel) lighting. Initially most people think that computing lighting at every pixel is slow. However, the Gouraud (per-vertex) shading model can perform worse than the Phong shading model when multiple vertices are on the same pixel on the screen. In that case, the same pixel has had multiple lighting calculations done on it. In the optimal case with Phong shading, rendering opaque objects near-to-far with early depth testing, we will perform lighting calculations on every pixel on the screen only once.
If we have 2 triangles that simply cover the whole screen, rendering it with the Phong shading model will be slower than with the Gouraud shading model, but the vertex shader in the Phong model is extremely simple. That means if we broke those two triangles into 250,000 triangles, our performance will be very similar to having just 2 triangles. A blanket of 250,000 triangle that cover the screen in the Gouraud model will, on the other hand, perform considerably worse than with 2 triangles.
The second reason is due to deferred shading. Deferred shading implies the Phong model, and guarantees only one lighting calculation for a given pixel per light (or less). Deferred shading uses multiple buffers (a G-buffer) to store the different parts of the render information, such as basic colors, normals, and depth. Lighting is then done over the rendered scene in 2D. This completely separates the lighting pass from the geometry-rendering pass, and means that the geometry is rendered only once, regardless of the number of lights. In forward shading, geometry is typically re-rendered for each light that casts a shadow. That means vertices sent back up the pipeline, re-transformed, etc.
In a scene with only one light that does not cast a shadow, deferred shading may not show any improvement over forward shading, but in a scene with 30 or 40 lights, deferred shading will pass forward shading by an astounding amount.
Closing
There are certainly more considerations taken into account regarding the performance of the graphics engine, but these two are two of the heavy hitters, and I consider them mandatory for any engine aimed at next-gen.
L. Spiro
