<div dir="ltr"><div><div><div><div>Hi all,<br><br></div>After stumbling across <a href="https://developer.blender.org/D1880">https://developer.blender.org/D1880</a>  (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.<br><br></div><div>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&#39;s going on)<br></div><div><br><br></div><div>== The Situation ==<br></div>We&#39;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.). <br><br></div>This was going to need to happen at some point, regardless of whether the OpenGL/viewport upgrade work goes ahead or not.  What&#39;s clear is that we want at least some kind of fragment shader to do a lot of fancy <br><br>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.<br><br><br></div>== Open Issues/Questions ==<br><div><div>1) Can we use geometry shaders? <br></div><div>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)?<br><br></div><div>2) What&#39;s the current plan (assuming there is one) for how we&#39;re going to transition Blender to using the modern GL, and how would it be best to fit this work in around that?<br></div><div>- At least initially, I&#39;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&#39;s ready of course).<br><br></div><div>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.)?<br><br></div><div>4) Where should the code go?<br></div><div>- Of course the GLSL shaders will go with the other shaders in the GPU module<br></div><div>- At least some wrapper functions will likely also migrate to the GPU module - just like with the other things there already<br></div><div>- What&#39;s unclear currently is how much this stuff can be tied into the GPU_shader api&#39;s, and how much we&#39;ll need a separate set of API&#39;s to manage this stuff<br><br></div><div>5) Regarding the vertex buffers/arrays...  (probably silly questions that would be answered by a FAQ, but since we&#39;re here):<br></div><div>- Can you refer to different buffers on different frames/redraws?  Or would that be &quot;bad&quot; (though not as bad as what we do with immediate mode currently anyway)?<br></div><div>- 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)?<br><br></div><div>I ask because it seems that a lot of the time, people are only dealing with animated character meshes whose geometry/topology doesn&#39;t change (i.e. no new bits added/removed on different frames), whereas with Grease Pencil, you&#39;re effectively doing replacement animation on each frame.<br></div><div><br><br><br></div><div>== Proposed Approach - Lines (Tentative) ==<br></div><div>At this stage, I&#39;ve been looking at various techniques trying to figure out which one is likely to be the closest to what we&#39;d want to be using for stroke drawing.<br><br></div><div>I&#39;m currently leaning towards using the technique described in the following paper as a base:<br>    Nicolas P. Rougier (2013). &quot;Shader-Based Antialiased, Dashed, Stroked Polylines&quot;  <br>    <a href="http://jcgt.org/published/0002/02/08/paper.pdf">http://jcgt.org/published/0002/02/08/paper.pdf</a><br></div><div>    (BSD Licensed code - for PyOpenGL + Numpy is also provided along with the paper)<br><br></div><div>but have also been considering the techniques in:<br>   - <a href="https://forum.libcinder.org/topic/smooth-thick-lines-using-geometry-shader">https://forum.libcinder.org/topic/smooth-thick-lines-using-geometry-shader</a><br>   - <a href="http://codeflow.org/entries/2012/aug/05/webgl-rendering-of-solid-trails/">http://codeflow.org/entries/2012/aug/05/webgl-rendering-of-solid-trails/</a><br></div><div>as alternatives, if we run into any difficulties.<br><br></div><div>That said, Rougier&#39;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&#39;s also an example of how it can be used in 2D and in 3D.<br><br></div><div>Stuff we&#39;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.<br><br></div><div><br>Thoughts? Suggestions?<br><br><br></div><div>== Proposed Approach - Dots/Discs/GLUQuadrics Replacements (Tentative) ==<br></div><div>I&#39;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 &quot;Volumetric Strokes&quot;).<br><br></div><div>It currently looks like we may end up doing something like:<br>   <a href="http://stackoverflow.com/a/27099691">http://stackoverflow.com/a/27099691</a><br><br></div><div>1) Is this one of those OpenGL API&#39;s that we&#39;ll be supporting in 2.7x, or is this something that&#39;s only available with later versions?<br></div><div>2) Does anyone know if the existing limits on line/point size (e.g. &quot;10&quot;) still apply?<br></div><div><br></div><div><br></div><div><br></div><div>Cheers,<br></div><div>Joshua<br><br></div><div>(Grease Pencil Dev/Maintainer, and Rendering/OpenGL/GLSL noob ;)<br></div></div></div>