I was hoping for the deconstruction (or reconstruction) of one of the many rendering engines already out there - there's lots to talk about! This doesn't have

I was hoping for the deconstruction (or reconstruction) of one of the many rendering engines already out there - there's lots to talk about! This doesn't have much meat - reads like an incomplete UML diagram. My experience is mostly porting/profiling/optimizing graphics, not writing entirely new pipelines, but I'll chime in on a couple points: >> Passes can receive as inputs: [...] The previous Pass outputs in the form of textures in memory (Render Targets) This feels a bit arbitrarily limited. I find rendering passes more 'graph-like' than a pure linear pipeline. For example, you might render some shadow maps - some of these might be bound to a single camera (e.g. for traditional directional cascading shadow maps fit to the camera frustum), but other shadowmaps could easily be shared between multiple viewpoints (e.g. point light dual paraboloid shadow maps). And even your 'per-camera' shadowmaps might be reused between multiple viewports for e.g. two very similar eye cameras in VR, whereas other parts of your scene will need to be re-rendered wholescale per-eye (unless you start implementing e.g. nVidia's single-pass multi-viewport rendering - how does that fit into this UML diagram?) And then of course you might have multiple passes reading from the same gbuffer(s) or the scene depth buffer, or even the result of previous frames (temporal anti-aliasing and motion blur), and other things that aren't really per-camera (dynamic light probes for reflections, etc.) I've also 'fond' memories of bugs from the magic configuration of passes, inferring inputs and outputs from their position in a list. I'd lean strongly towards being completely explicit about inputs and outputs. It's more dumb code, but it'll make things beautifully straightforward to understand, modify, and fix. >> The basic concept of boiling things down into passes with inputs and outputs that can be managed as data This has been overkill for every single one of my hobby projects, just more cruft to wade through, a solution searching for a problem. At least one of the more graphically simple professional titles I've worked on didn't even bother with this, and I didn't miss it. That said, the professional rendering code I'm most familiar with (having ported it from D3D9-only to multiple other rendering APIs) did have something similar, and it seemed reasonable enough. If you want to go "crazy" exposing control of rendering passes directly to your artists to tweak with scripts or other UI, it's a reasonable thing to represent. It can also make adding some debug tooling easier (e.g. profiling information about different passes, adding debug views of the outputs of individual stages, etc.) A nifty graphics study of DOOM: http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/ http://www.adriancourreges.com/blog/2016/09/09/doom-2016-gra...