» DirectX 11 zero0.org

Tag Archives: DirectX 11

PBuffer and Post-Processes

I posted the following on the Card Kingdom development blog.

One neat concept I learned about while researching deferred rendering was the PBuffer. The PBuffer is used for post-process effects and contains at least two screen-sized render targets that are swapped between each other while rendering each post-process effect sequentially. The final image from one effect is used as input for the next, creating a daisy chain of accumulating effects. To expand the number of possible effects the PBuffer can support, half and quarter-sized buffers can be used to scale down the previously rendered effect and used to support other effects (e.g. bloom).

More Lightning and Shadows

I posted the following on the Card Kingdom development blog.

More Lightning

In a somewhat recent post, I showed off the initial stages of the lightning effect that I’ve been working on. One of the major hurtles that was tripping me up, and the reason why in the old video it is hard to actually see the lightning, was the blend states in DirectX 11. There is a flag in the blend state descriptor called IndependentBlendEnable. If this is set the false, all render targets that are bound only use the first render target blend descriptor. For many applications this works perfectly fine. For others, this breaks everything. Well, not break per-se, but gives unintended, unwanted, and incorrect results. So, the issue that I was running into was when rendering the depth render target, the blend mode was set to additive. It was trying to additively blend the depth with an already existing depth value or zero from the depth render target. The fix was to specify IndependentBlendEnable = true and define the depth render target to use an alpha blend to overwrite any value that was previously rendered.

Deferred Particles and Lightning

I posted the following on the Card Kingdom development blog.

Deferred Particles

As with other parts of the engine, the entire particle system was updated to use a similar deferred rendering method as the regular geometry. This really improves the look of the particles, in particular smoke and dust, as it gives them a more “volumetric” look. All the particles now interact with the lights in the scene just as the regular geometry does.

Tool Time – Particles, UI, and Resources

I posted the following on the Card Kingdom development blog.

Particle Editor and UI Communication

One of the newest features I’ve been working on was the in-engine particle editor. This was a great test for the communication from the UI to the engine, and back again. In developing, this was the “worst case” scenario for communication as there are many parameters that can be set for the particles. Designing a system that could handle this case, as well as simpler ones was vital in making the UI flexible and extensible.

The solution I came up with an event listener and caller system. Using our internal messaging system, components register themselves as event listeners to one or multiple events and can retrieve the event caller for the UI.

Deferred Rendering In Card Kingdom

I posted the following on the Card Kingdom development blog.

Background

One of the major updates to Card Kingdom going forward is a complete rewrite of the rendering pipeline. In the original version, the alpha version essentially, we used a”forward rendering” style for our rendering process. In a forward rendering system, all lighting information is calculated when the mesh is rendered to the screen. For scenes with multiple lights, the mesh would have to be drawn for each light and blended together to get the final image. For non-complex, low lighting count scenes, forward rendering is straight forward and works well. As the number of lights and the complexity of the geometry that is being rendered increases, the processing time drastically increases. The complexity can be modeled as O( n * m ), where n is number of triangles, meshes, objects to render, and m is the number of lights in the scene. Rendering times drastically increase when more lights and triangles are drown. This is why the number of supported lights is usually around 8.

Who Needs Flash…

I posted the following on the Card Kingdom development blog.

In a previous post of mine, I sung the praises of using straight Flash as a UI system. In theory and practice, it works in the form of Scaleform. Flash offers many nice graphical features that would be difficult to rendering normally. The implementation I used basically wrapped the Shockwave COM object and exposed many of it’s methods in an easy way. Rendering was more complex as I had to get access to a DirectX 11 Texture’s GDI context in order to render to it. This process worked, but not really.

Tool Time – Focus and the Model Viewer

I posted the following on the Card Kingdom development blog.

Along with the Combat Corner and Designer’s Den, I want these Tool Time posts to be about tool development, not just on Card Kingdom, but for general tool development. I want to discuss how to make everyone on the team’s life easier when dealing with an engine by making smart decisions about form and functionality.

Card Kingdom

Card Kingdom is a 3D arena-style brawler where the player controls an anthropomorphized playing card that defeats overwhelming numbers of zombified cards raised by the evil Joker to conquer Card Kingdom.

Lighting, Cel Shading, and Shadows

I posted the following on the Card Kingdom development blog.

Light and shadow are the two basic visual cues that give objects depth and position. Light shows off the detail of the object, giving it form. Shadow gives context to the object’s location relative to the other objects around it. These two together give great depth to an otherwise flat image.

In terms of the engine, light can be done using two types of lights: point lights and directional lights. Point lights (e.g. light bulbs, candles) give off localized light that falls off over distance. Directional lights (e.g. sun light) give off global, uniform light across all objects that it hits. Though different in there uses, the calculations are basically the same.