BEER design meeting 27-09-2015


#1

Note 1: BEER dev fund status: 21% (~USD 4200). We need USD 20k.
Note 2: BEER is non-photorealistic OpenGL renderer for Blender.
Note 3: Meeting via FB group PM

Render passes, render layer & compositing

Current Blender Internal (BI) & Cycles design:

  • distribute objects in render layers.
  • render each render layer, each render layer is broken down to passes for compositing.
  • composite render layers and passes.
  • get final raster image.

BEER does all of that in one go in GLSL.
(If you understand how GLSL works, skip this part.)

  • The object material is a shader stacking system.
  • Each layer is a pass hence can have post effect at any stage.
  • Screen effects & world post effects are put last as they change a lot of pre-rendered objects.
  • Then assemble all the parts to be displayed on screen for raster rendering.

Where will Freestyle or contour shader be with BEER?
Line post effect will be a layer of post effect.
Calculation will be more isolated (smaller) and hence better performance.

Is render pass (post effect) just another shader layer?
Yes. It works just like adjustment layer in Photoshop.

Where is render layer?
The whole process resembles the whole render layer to compositing workflow. The only difference, in BEER we can composite before it reach rastering stage. Thus we can remove render layer altogether.

We need render layer (in BI & Cycles) because we need layers for compositing in the first place. If compositing is done “between” shader layers, render layer is ancient relic. We don’t need it in BEER.

The really difficult part is making the arrows in the diagram work.


TL;DR: Composite everywhere. No render layer. Render passes on every shader layer. Post effects on render pass is a shader layer.


Next week’s topic: How to split BEER & related works? Avoid 4 year plan, build the core in 1 year or less.

Question:
Do you want to participate in the meeting?
If you have made realtime apps/games, we want people like you.
Meeting time: after Blender dev weekly meeting (Sunday 1400 UTC)
Location: Facebook group private message


#2

a few notes:

  1. some of the ideas behind the graph above comes from things discussed
    about on #blender irc, mailing list and from this post:
    http://code.blender.org/2014/12/future-viewport-the-design/
    especially in the last paragraph.
  2. The ‘difficult arrows’ mean that each GLSL code fragment should be able to be stacked in meaningful ways with all the others, defining standard but flexible ins, outs and uniforms that allow everything to work together. The ‘deferred rendering’ pass mentioned in the blog post is something that here is considered ‘compositing’.
  3. Everything is still open to change and better interpretations. I don’t know what are BF’s plan for the compositor, but in my opinion a new compositor that can run GLSL Compute operations would be REALLY interesting to have, evem for Cycle use.
  4. Another difficult part will be understanding how to split this in smaller, self contained projects that will hopefully be useful for all of Blender. The more obvious is the Viewport project, since things are shaping up in a very similar way.
  5. Hate me if you want, but I can’t wait to be able to write code instead of nodes :wink:

Roberto