[Bf-viewport] Current state of Blender GL refactoring

[Mike Erwin]

Hi Yury,
Thanks for kicking this mailing list back to life! I saw you asked about
the OpenGL migration in #blendercoders, hopefully we'll be on there at the
same time soon and can chat about it. Is this something you could help out
with code-wise? Design-wise?

My rambling response is a mix of "what do we want" and "how do we do
that?", but I hope you find it mostly on-topic.

Here's what I'm working on now and near future:

OpenSubdiv -- Getting it working on more platforms, investigating bugs,
filling in holes. For B 2.8 hopefully this will be rock solid and we can
have OSD as the one true subd system -- it will NOT be optional. It's
progressing nicely but the big GL upgrade needs to happen before it will
run on MacOS.

I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
2.1 as a baseline and convert all code that uses obsolete extensions to the
functions/enums provided by GL itself. Much of this is simply deleting ARB
or EXT, and removing checks for GL features that are guaranteed in 2.1. No
new features, no major rewriting, just get the code up to spec and ready to
branch for the bigger GL 3.2 upgrade. This can be done NOW and doesn't
involve any design really -- just a plan of what to remove/convert. Is
anyone opposed to this? Anyone eager to help?

Medium future / 2.8:

Interop with external game engines. Authoring of assets for games
(including real-time materials) is a big goal. Make them in Blender,
migrate them to native UE4 materials for example. I'll be working on this a
lot in the coming months.

Setting GL 3.2 as our new baseline is such a relief! Guaranteed geometry
shader support and a nicer GLSL overall. Anything that uses GL > 3.2 will
be optional or require a compatible fallback. But really 3.2 gives us a big
enough playground to get the vast majority of cool things done.

Staged migration of OpenGL:
now --> GL 2.1 (all platforms) --> 3.2 compatibility profile (Windows &
Linux) --> 3.2 core profile (all platforms)
That final transition will be the most work.

Toss display modes (box/wireframe/solid/texture/material) and think about
the different ways we want look at our 3D work-in-progress. Sometimes we
want to see the surface with full materials, well lit, like reality on
screen. Other times just the shape or form of an object, like when
sculpting. Or the way an object is constructed out of polygons. Use the old
terminology to describe what we want in 2.8 but don't get stuck in existing
modes. Had some good conversations about this at BConf.

Your #3 (light & shadow preview) seems to fit into this bigger topic --^

Some real-time shaders can be considered functionality or UI, part of your
workflow, built into Blender. Other shaders can be considered content /
assets / work / play. This is true for today's Blender (matcaps are UI,
materials are assets) but things are going to get much more interesting in
the next year!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Nov 20, 2015 at 9:49 AM, Yury Baranov <cucumberer at gmail.com> wrote:

> Hi everyone. I suggest you to describe what features (and possibilities)
> new Blender GL should have (a.k.a. Technical Requirements) and what in your
> opinion should be optional, and what not. And let's imagine that we not
> limited with current Blender code - let's just try to design the target
> state, and then we will find the ways to solve this horde of problems.
>
> Please point me if it was described somewhere else.
>
> Let me start:
> 1. Viewport must be fast enough for sculpting. Every modern pipeline
> (games/movies/etc) includes 3d-sculpt, so this is "must-have".
> 2. Possibility for addons to do something in viewport via python.
> RetopoFlow addon and Mesh-Controls for armature (like in Pixar's Presto[1])
> are pretty good examples.
> 3. Possibility for lighting and shading preview (it will be nice if
> simplified lights and shadows preview will be available for any render
> engine, not only BI)
>
> [1] https://vimeo.com/90687696
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20151120/c5c24219/attachment.htm