4 ms·

I would be curious to see what anyone with more than my armchair experience in graphics thinks of this.

by foota 10y ago

MaulingMonkey 10y ago
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...
- sillysaurus3 10y ago
  Hey, it's MaulingMonkey! I spent most of my childhood on #gamedev. (Is Washu still around?) Thanks for the countless hours debating random programming topics. #gamedev was a pretty wonderful incubator for a 14 year old. Whenever I ran into a wall that couldn't be solved with googling, someone was usually able to give some sort of tip or an arcane D3D incantation to point me in the right direction. Hope you've been well!
  - MaulingMonkey 10y ago
    I grab dinner with Washu sometimes :). I hear he's been hanging out in the discord chat more often now, but still pops into #gamedev some as well. Also un-retired into game development out of boredom. Been well, hope the same for you :).
flohofwoe 10y ago
Variations of this design are quite common in realtime rendering engines after people realised that putting everything into a single giant scene graph isn't a good idea (so at least since the very early 2000's). For instance in our engines (Nebula2 and 3) there are so-called "frameshader" files (XML, nowadays it would be JSON of course) which describes a frame as a sequence of passes, the result of a pass is a valid render target texture or the final visible image, and a pass consists of per-material batches (or buckets). Higher up are 'stages, views, and entities', a stage is a collection of graphics entities, a view is a 'view into a stage' (a view owns a camera and a frameshader), and entities can be models, lights and cameras. Multiple views can be attached to the same stage, and views can depend on each other (although in the >10 years we use this concept, dependent views were hardly needed).
- Mayzie 10y ago
  > people realised that putting everything into a single giant scene graph isn't a good idea (so at least since the very early 2000's). Why?
  - flohofwoe 10y ago
    Go to Tom Forsyth's blog here: https://tomforsyth1000.github.io/blog.wiki.html https://tomforsyth1000.github.io/blog.wiki.html and find the "Scene Graphs - just say no" post (I failed at providing a direct link, apologies).
    - detaro 10y ago
      direct link: https://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D https://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%...
  - theprotocol 10y ago
    A high-level intuitive, if simplistic answer, would be that you want to do batching based on type, and a monolithic scene graph does not arrange things by type; nor is it in general a valuable abstraction for rendering graphics, which are ultimately highly non-hierarchical and undermined by the constant need for sophisticated traversal logic.
dreta 10y ago
This post is an example of armchair programming, so your armchair experience is more than enough. On a more serious note, it's software architecture done on paper. Any experienced programmer will tell you it's close to worthless. You don't have to be a graphics expert. Abstraction of passes and pipelines isn't anything new, it even bled into the modern APIs like Vulkan. This post is just some inexperienced programmer's vague description of how he or she would like things to work in theory. It's not worth a discussion.
- zimorodek 10y ago
  I think the pipelines in this posts mean something different. As Vulkan/Metal pipelines refer to the GPU rendering pipeline with vertex, fragment shaders, tesselation etc not a sequence of passes.

I would be curious to see what anyone with more than my armchair experience in graphics thinks of this.

by foota 10y ago

I would be curious to see what anyone with more than my armchair experience in graphics thinks of this.

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...

sillysaurus3 10y ago
Hey, it's MaulingMonkey! I spent most of my childhood on #gamedev. (Is Washu still around?) Thanks for the countless hours debating random programming topics. #gamedev was a pretty wonderful incubator for a 14 year old. Whenever I ran into a wall that couldn't be solved with googling, someone was usually able to give some sort of tip or an arcane D3D incantation to point me in the right direction. Hope you've been well!
- MaulingMonkey 10y ago
  I grab dinner with Washu sometimes :). I hear he's been hanging out in the discord chat more often now, but still pops into #gamedev some as well. Also un-retired into game development out of boredom. Been well, hope the same for you :).

flohofwoe 10y ago

Variations of this design are quite common in realtime rendering engines after people realised that putting everything into a single giant scene graph isn't a good idea (so at least since the very early 2000's). For instance in our engines (Nebula2 and 3) there are so-called "frameshader" files (XML, nowadays it would be JSON of course) which describes a frame as a sequence of passes, the result of a pass is a valid render target texture or the final visible image, and a pass consists of per-material batches (or buckets). Higher up are 'stages, views, and entities', a stage is a collection of graphics entities, a view is a 'view into a stage' (a view owns a camera and a frameshader), and entities can be models, lights and cameras. Multiple views can be attached to the same stage, and views can depend on each other (although in the >10 years we use this concept, dependent views were hardly needed).

Mayzie 10y ago
> people realised that putting everything into a single giant scene graph isn't a good idea (so at least since the very early 2000's). Why?
- flohofwoe 10y ago
  Go to Tom Forsyth's blog here: https://tomforsyth1000.github.io/blog.wiki.html https://tomforsyth1000.github.io/blog.wiki.html and find the "Scene Graphs - just say no" post (I failed at providing a direct link, apologies).
  - detaro 10y ago
    direct link: https://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D https://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%...
- theprotocol 10y ago
  A high-level intuitive, if simplistic answer, would be that you want to do batching based on type, and a monolithic scene graph does not arrange things by type; nor is it in general a valuable abstraction for rendering graphics, which are ultimately highly non-hierarchical and undermined by the constant need for sophisticated traversal logic.

dreta 10y ago

This post is an example of armchair programming, so your armchair experience is more than enough. On a more serious note, it's software architecture done on paper. Any experienced programmer will tell you it's close to worthless. You don't have to be a graphics expert. Abstraction of passes and pipelines isn't anything new, it even bled into the modern APIs like Vulkan. This post is just some inexperienced programmer's vague description of how he or she would like things to work in theory. It's not worth a discussion.

zimorodek 10y ago
I think the pipelines in this posts mean something different. As Vulkan/Metal pipelines refer to the GPU rendering pipeline with vertex, fragment shaders, tesselation etc not a sequence of passes.