Jump to content
  • Advertisement
Sign in to follow this  

modular pass-based (forward / deferred) rendering

This topic is 2830 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


For the next 5 months I will be working on a rendering engine (very bare bone) for a school project. The main requirement is to have an innovating key feature like deferred rendering used to be 5 years ago. Because I am fairly new to graphic programming (on this level, I have done 2D and some XNA and a little DirectX9 back in the day) I would like to ask what such an innovating (relatively new) feature could be.

I do have an idea of my own but I'm not sure if its new or actually doable.

My idea is to build a pass-bases render system in which shaders (diffuse, normal, SSAO) can be linked together to form passes.
A forward rendering configuration path would typically have one pass which does the diffuse, normal and light. A Deferred rendering configuration would have the base pass which renders the diffuse, normal, specular and depth to seperate textures which can be used in following passes. A next pass could be the light and pass after that SSAO (or they run concurrently). So each shader has required input and output. Some shaders can be linked together to form a pass because they dont interfere with each other, some do and have to be in a separate pass and has to wait. Also the passes used are exposed to the material system so only used parameters are available.

This might all be too vague and i'm not sure if this is really something but all feedback about this and how to manage shaders or passes is welcome.
Also I am really curious about any suggestions on how to go about this 'innovating' factor. Please help smile.png


Wouter Edited by woutervd

Share this post

Link to post
Share on other sites
What you described sounds like a tree based system for rendering passes, using adaptive inputs and outputs. A 'compile' step would check to see if two adjacent passes could be collapsed into a single pass; Sounds like fun.

Take a brief look at the shader editor in the UDK, its a node based system that generates a shader based on connected inputs & outputs. If your passes (nodes) are discreet enough, then it should be trivial to create a wrapper function that can call both and direct re-direct outputs to multiple bound rendertargets etc.

A similar system i've written worked on the concept of meta-targets. A pixel shader could declare say, 40 outputs of different types, then the compiler would take hardware MRT limitations and create multi-pass shaders that tightly packed those into the appropriately bound rendertargets for each pass. So, in the case of say, 40 float2 outputs, on a machine that only supported 4 simultanous targets, it would create 5 passes (40 float2s == 20 float4s, 20 / 4 RTs = 5 passes)

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!