
The Compositing Tree (2014) - antigizmo
http://nothings.org/gamedev/compositing_tree/
======
jheriko
this reads confused, but i found it interesting precisely because of that...

the whole discourse on the over operator and compositing trees makes a real
meal out of something very simple. i'm not sure that "order of compositing
doesn't matter" (vs. order in layers) is a particularly deep insight... its
the sort of thing we just intuitively know from real-life experience afaik.
not worthy of a discussion with trees and equations...

i'd be curious why the author got stuck with compositing frame buffers
together though - this is usually very avoidable, even in the cases described,
and even on old hardware. i'm guessing there are some /really/ hairy edge case
things that are not mentioned...

also, all this talk as if everything is built with dynamic, upload-every-
frame, vertex buffers as well, instead of (given that its 2d) some well
organised quad renderer... i doubt changing shader/material parameters was the
dominant cost somehow.

there are certainly somethings you like to do in 2d (post-processing filters)
that are hard in 3d, but drawing your basic stuff isn't one of them - there is
no mystical difference between 2d and 3d, one is just a subset of the other -
if you ignore the hacky pixel space stuff we do in post (which we can also do
over 3d renders) which is a trick of the representation (pixels) and not the
geometric space (2d).

~~~
joeld42
I don't think you read it very carefully. Some of the operators he's
supporting are not OVERs. These "filter effects" and blends are non-
associative and that's where the tricky stuff comes in.

