Reaching my next objective proved remarkably easy in XNA. First and foremost, a big thanks to Catalin Zima. I started from his deferred shading tutorial to build my own pipeline. I liked a lot of aspects of the deferred pipeline back at 10tacle, so I want to start with a deferred pipeline for my own engine as well. I’ve implemented Catalin Zima’s tutorial, but refactored it into a system of clean, separated steps. A RenderContext in Hyperion now contains a set of Cameras and a set of RenderSteps. I’ve designed a clean IRenderStep interface, which will hopefully allow me to add about any effect/rendering technique to my pipeline easily without the need for a lot of refactoring. Implementing the deferred pipeline that way was straightforward, so now I have a basic deferred renderer, with a lighting pass allowing for dynamic directional, point & spotlights.
I’ve put some thought into the interaction of these RenderSteps with the game objects, and have found an elegant solution for that. Game entities ( which are just components, just like almost anything in the engine ) register to any render context they want to be rendered in, and specify their renderable type (e.g. DeferredModel, or PointLight). Within each render context, this instance is passed to each Render Step. The render step can decide to render or not this particular entity. So now I have e.g. very simple game entities for lighting entities, and they’ll integrate into my editor automatically with the rest of the entities. I plan to add the possible extensions to the deferred rendering pipeline Catalin Zima suggests soon, but I had something else in mind first.
Since one of my goals is the easy experimentation with graphic effects, I wanted to put some effort into automatic graphical debugging capabilities of the rendering pipeline. I really dislike ingame debugging with an extensive set of keyboard shortcuts or console commands. It typically is obscure, cumbersome and hard to maintain. So I’m going about it the other way. I’m creating a basic .NET WinForms application that will serve as both editor & debugger for games running on the Hyperion engine – working title ‘playground’. In this editor, I’m running an instance of the game itself, and editing or debugging game elements will happen through panels automatically generated based on information extracted from the game via reflection. Similar to 3d modeling packages, you can have any number of different viewports into the game, showing any information you want to. And hey, that worked out just fine!
So, what’s going on behind the screens? (pun not intended)
- There’s an actual game instance running in a custom control. At the moment, this game is just updated like a normal game, so it’s just running, but it will be trivial to add pause & slow motion controls in the editor when I need them
- I’ve added DebugRenderSteps into my rendering pipeline that will output anything to the main render target, and exit from the pipeline. For instance, in one kind of DebugRenderStep, any color render target is just output, the same kind of DebugRenderStep is used for normal render targets but with a different shader, etc.
- In my editor, I use .NET’s reflection to list the registered DebugRenderStep’s in the viewport’s context menu. So activating any debug view takes just 2 mouse clicks.
- There are several, predefined viewport layouts possible: one big viewport, two viewports vertical, four viewports, …
- Any viewport’s camera is controllable by just doubleclicking the viewport, at which point input control is given to the game until the user presses Escape.
- A separate camera is created per viewport, but it is equally possible to show the same camera in several viewports, as shown in this screenshot:
None of this is all that special, and has been done tons of times before. But the speed at which this is possible in C#/XNA is motivating to say the least. Next stop: Rayleigh/Mie scattering, aka Crysis-style dynamic skybox. Stay tuned.