[Bf-viewport] Current state of Blender GL refactoring

[Yury Baranov]

Hi Mike! Thank you for your anwser.
I think everything that you suggest is great, but maybe this plan:
"now --> GL 2.1 (all platforms) --> 3.2 compatibility profile (Windows &
Linux) --> 3.2 core profile (all platforms)"
is not so good because second step (which can be done just now) is
unnecessary passphase which offers no benefit for next steps if I
understand correctly.

2015-11-21 6:51 GMT+03:00 Mike Erwin <significant.bit at gmail.com>:

> 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
>>
>>
>
> _______________________________________________
> 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/20151124/ac823d55/attachment.htm