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

[Mike Erwin]

The entire GLU library is going away for Blender 2.8 (
developer.blender.org/T49042). I was looking for the next item for this
task, found drawgpencil.c and remembered this email thread. Much of grease
pencil drawing needs to be redone, and I'm glad you've already been
thinking about the options!

Geometry shaders can play a big part in stroke drawing. Pass in 3D
positions + 1D width, out pop nice continuous flat ribbons or tapered
tubes. We can add a custom built-in shader for each drawing style needed. I
recently added some new built-in shaders -- the GPU_shader API met my needs
and was easy to use & build upon.

I think this sort of work can happen directly in the blender2.8 branch. We
have a long time for experimental things to settle down before shipping. If
you'd rather work in a branch, base it off of blender2.8 (not master).

Whenever you're ready to start on this I'll be around to help with the
OpenGL side & provide supporting GPU library code. Sooner would be great
but I don't know your schedule.

Blender 2.7x will continue to use OpenGL 2.1 + GLU so we can leave that
code alone.

Details about buffers & implementation limits we can figure out as needed.
Any GPU on Mac can do points up to 64 pixels -- but working with geometry
shaders will be much easier on Windows or Linux until we get Mac up to
speed. And removing GLU gets us one step closer to modern GL across all
platforms.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sun, Apr 3, 2016 at 11:58 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> Hi,
>
> On Sun, Apr 3, 2016 at 4:52 PM, Joshua Leung <aligorith at gmail.com> wrote:
> > 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.
>
> Custom shaders for grease pencil makes sense. We don't need the
> overhead of advanced patterns and caps for basic line drawing in the
> UI.
>
> We still have to start refactoring the current GLSL shading code to
> take more advantage of modern OpenGL functions. But regardless it's
> not complicated to create custom GLSL shaders now, the messy stuff is
> wrapped in pretty easy to use functions.
>
> > == 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)?
>
> Generally the plan has been that we will require OpenGL 3.2 for
> Blender 2.8, which would include geometry shaders.
> https://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL
>
> But indeed there are issues on Mac until we are done a lot of OpenGL
> refactoring switch to the core profile, and of course it's unclear
> still when 2.8 will actually happen.
>
> > 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).
>
> I don't know to be honest, there has been that much progress on OpenGL
> refactoring on Blender 2.8 recently, so I don't dare to give any
> specific dates. You can always implement the geometry shader code on
> the CPU if you want to merge it earlier, it might not be so hard to
> port such code between the CPU and GPU.
>
> > 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.)?
>
> Not more than when doing other OpenGL drawing. Mostly you just have to
> bind the GLSL shader and unbind it when you're done with it, there is
> less state to worry about. When you bind a GLSL shader then some
> OpenGL states like materials or lighting become irrelevant, while
> other states like blend modes or backface culling still have an
> effect.
>
> > 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
>
> Currently we have keep most of this stuff in the GPU module, but it
> wasn't really a conscious decision to have it centralized as far as I
> know. If it's possible to make the GPU side fairly generic and not
> tied to grease pencil data structures, then I'd suggest to put it in
> the GPU module.
>
> > 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.
>
> It's a matter of performance. You can allocate/free buffers on every
> frame fine, it's just more overhead than reusing a fixed buffer and
> updating its contents. For optimal performance you might even have
> double buffering, so that you can write to one buffer on the CPU while
> the GPU or CPU driver is drawing the other buffer.
>
> Of course the actual performance depends on a lot of factors, and the
> allocation/free may or may not be significant in practice. I'd just
> start with reallocating the buffers every frame, or at least whenever
> their size must be increased, and then you can figure out from there
> if it's worth optimizing further. Looping over all the frames to
> figure out the optimal buffer size has its own overhead too.
>
> > == Proposed Approach - Lines (Tentative) ==
> > 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?
>
> The paper seems quite good, I haven't really though about these
> algorithms much so not sure which one would be best.
>
> > == 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?
>
> The maximum is still entirely up to the implementation. I don't know
> if there is some common minimum supported size that exists on all GPUs
> we support, I couldn't find information about that, probably it's not
> a good idea to rely on such a thing.
>
> We don't really have a plan yet for replacing these specific
> functions. I imagine we'd have some utility functions to easily draw
> various shapes. If you need them now you can implement them, and then
> later they could be folded into a more general API.
>
> Regards,
> Brecht.
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160822/5c26e83a/attachment.htm