[Bf-viewport] Grease Pencil Roadmap vs Viewport/OpenGL Work

[Joshua Leung]

Hi all,

After stumbling across https://developer.blender.org/D1880  (Wide Lines +
Stipple replacement for new OpenGL) and the associated discussions, I
figured it would be worthwhile to touch base with the OpenGL gurus here to
coordinate a bit about how/when/what is going to happen with regard to
Grease Pencil drawing and modern OpenGL stuff.

Long-ish mail follows...  (Maybe some of these sections could go into
separate threads, but it might be easier this way to get the full picture
of what's going on)


== The Situation ==
We're going to need to overhaul Grease Pencil drawing in the next few
months/year to start using GLSL shaders, to solve various line quality +
artistic-control issues that we currently have with the strokes (e.g.
strokes thicker than 10 px, without nasty segmenting/overlap artifacts on
sharp corners, control over end caps, AA, stroke appearance/styling, etc.).

This was going to need to happen at some point, regardless of whether the
OpenGL/viewport upgrade work goes ahead or not.  What's clear is that we
want at least some kind of fragment shader to do a lot of fancy

While I was originally planning on just waiting to see what replacements
for the old OpenGL stuff came up (e.g. similar to D1880), I now think that
we might be better off creating a set of custom shaders for Grease Pencil
stroke drawing, so that we can have full control over what strokes can and
cannot do, without having to worry about breaking anything else. Plus,
Grease Pencil strokes will eventually need a bit more fanciness than simple
UI elements will need.


== Open Issues/Questions ==
1) Can we use geometry shaders?
It looks like the OpenSubdiv stuff already gets to do this via an
extension, so can we assume that this can work in a similar way too?  But,
would using geometry shaders mean we run into those legacy vs modern GL
context issues on Mac (i.e. no geometry shaders work until all of Blender
is ready to use the new profile)?

2) What's the current plan (assuming there is one) for how we're going to
transition Blender to using the modern GL, and how would it be best to fit
this work in around that?
- At least initially, I'll likely work on this in a branch - just to try
out some approaches, get some experience with how this all works out, and
hopefully stabilise it all. The main question then would be where this
branch gets merged, and when (when it's ready of course).

3) Are there any special precautions/policies I should be aware of when it
comes to managing GLSL shader stuff? (i.e. Do I need to reset things to
certain default states, etc.)?

4) Where should the code go?
- Of course the GLSL shaders will go with the other shaders in the GPU
module
- At least some wrapper functions will likely also migrate to the GPU
module - just like with the other things there already
- What's unclear currently is how much this stuff can be tied into the
GPU_shader api's, and how much we'll need a separate set of API's to manage
this stuff

5) Regarding the vertex buffers/arrays...  (probably silly questions that
would be answered by a FAQ, but since we're here):
- Can you refer to different buffers on different frames/redraws?  Or would
that be "bad" (though not as bad as what we do with immediate mode
currently anyway)?
- If we can only use a single buffer across frames, can the number of
vertices in the buffer change (or do we need to keep that constant - i.e.
figure out the frame with the largest number of points, create a buffer of
that size, and only populate it with as much data as needed on all other
frames)?

I ask because it seems that a lot of the time, people are only dealing with
animated character meshes whose geometry/topology doesn't change (i.e. no
new bits added/removed on different frames), whereas with Grease Pencil,
you're effectively doing replacement animation on each frame.



== Proposed Approach - Lines (Tentative) ==
At this stage, I've been looking at various techniques trying to figure out
which one is likely to be the closest to what we'd want to be using for
stroke drawing.

I'm currently leaning towards using the technique described in the
following paper as a base:
    Nicolas P. Rougier (2013). "Shader-Based Antialiased, Dashed, Stroked
Polylines"
    http://jcgt.org/published/0002/02/08/paper.pdf
    (BSD Licensed code - for PyOpenGL + Numpy is also provided along with
the paper)

but have also been considering the techniques in:
   -
https://forum.libcinder.org/topic/smooth-thick-lines-using-geometry-shader
   -
http://codeflow.org/entries/2012/aug/05/webgl-rendering-of-solid-trails/
as alternatives, if we run into any difficulties.

That said, Rougier's technique seems to provide a lot more of the things
artists would want already (in particular, the cap style stuff, and builtin
ability to do dashed lines too). There's also an example of how it can be
used in 2D and in 3D.

Stuff we'd have to hack into these would be: 1) ability to have varying
thickness and/or opacity based on pressure, 2) ability to use absolute
worldspace size vs absolute screenspace size.


Thoughts? Suggestions?


== Proposed Approach - Dots/Discs/GLUQuadrics Replacements (Tentative) ==
I've also been looking into techniques for replacing a lot of the current
GLUQuadric stuff (used for the single-point strokes, as well as for drawing
"Volumetric Strokes").

It currently looks like we may end up doing something like:
   http://stackoverflow.com/a/27099691

1) Is this one of those OpenGL API's that we'll be supporting in 2.7x, or
is this something that's only available with later versions?
2) Does anyone know if the existing limits on line/point size (e.g. "10")
still apply?



Cheers,
Joshua

(Grease Pencil Dev/Maintainer, and Rendering/OpenGL/GLSL noob ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160404/67e9a36a/attachment.htm