🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Rendering Data Flow

Published February 03, 2010
Advertisement

Rendering Data Flow

After doing some refinement on my renderer interfaces, I decided to revisit my rendering notation investigations and see how they could be implemented into my renderer. The basic concept turns out to be a well worn concept, which I'll discuss in this post.

During my thesis research, I used the Visualization Tool Kit (VTK) fairly extensively. For those who haven't had the chance to use it, it is an open source library for data analysis and visualization used commonly in medical imaging techniques. The data processing and visualization is accomplished by creating data objects via an importer, and then instantiating a number of 'Algorithm' objects, linking them together into a pipeline with your data as an input, and then executing the pipeline. This let's you create individual algorithm objects, and then later string them together to accomplish a particular overall task.

This type of processing is loosely known as a data flow paradigm. Of course, VTK isn't the first or only library to use such a system. DirectShow uses the exact same idea, letting you connect filters from together to processing input from sources and output to sinks. While reviewing my rendering notation, I kept going back to seeing how resources are modified by some large scale operation object (which I had called RenderViews). In this case, the resources were somewhat like nodes between each operation object, with the final output being the render target view of the appropriate swap chain for my window.

In all of my applications up to this point, I explicitly create each of the resources between operations. For example, in an SSAO setup I would create a depth texture, an occlusion texture, and the final render target output. I could then create the RenderViews to link them all together, and then execute each one in the proper sequence. However, this was actually quite cumbersome when trying to prototype an algorithm. I wanted to find a way to make it easier to link the operations together...

The solution is to follow a more data flow oriented concept similar to VTK or DirectShow. In those libraries, they connected the operation objects together and the resources needed between them are automatically created and managed based on the description of the input/output resources or defaults. In the SSAO example, I would just create the output render target view and then link the linear depth render view to the occlusion calculation render view, then link the occlusion calculation to the final perspective render view. The input to the whole graph of objects is a scene graph, which fits nicely with my existing object framework.

I'm in the middle of getting the actual design finished up, and then I need to try it out and see how well it works. I think it will be a nice addition to the engine...
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement