[Bf-gamedev] [Bf-viewport] Viewport and shader system patches

Sun Jan 10 17:23:09 CET 2016

Ton,

I forgot to mention: yes, I'll publish it as open source as soon as
something works.

Cheers.

On Sun, Jan 10, 2016 at 12:16 PM, Ton Roosendaal <ton at blender.org> wrote:

> Hi Alberto,
>
> It's very nice that people develop own engines to use with Blender. But if
> you don't have that as a public project, then it's not relevant here.
>
> Here - on this mailing list - we target at working on Blender itself;
> which is a complete free/open source suite for artists to make compelling
> 3D content, including games or content for games. That is the main and
> first goal.
>
> For people who want to use their own engines with Blender, they can help
> by making sure we use designs that work in general - specifically also for
> others who would develop external engines - and in a way our own goals can
> be achieved as well.
>
> Within that context, feel welcome to share design proposals or code.
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> > On 9 Jan, 2016, at 19:21, Alberto Torres <kungfoobar at gmail.com> wrote:
> >
> > Hello Ton, Brecht,
> >
> > I've used Blender GLSL shaders extensively and I've been planning in
> making my own material architecture that can do many things the current
> GLSL nodes can't. For now it's a side project but once done it will be
> useful on my day work, too.
> >
> > So far I've "reverse engineered" the Material node, which does too many
> things, and I finally understand in detail what it does (and its warts). A
> great first step will be separating it in two stages: textures and lights.
> (In fact my current shader trees have two types of Material nodes,
> shadeless textures and textureless lighting). This would allow to add
> "stages" or "buffered channels" for deferred rendering and other advanced
> rendering techniques.
> >
> > Another step is having energy-conserving BRDF(s); I'm not sure whether
> we have this already in the GLSL library but it should be clear to the
> user, and set by default, to have FBR or FBR-like setups that are
> believable and easy to tweak.
> >
> > Another important feature is having object-controlled parameters instead
> of being per-material. To some degree, this is already possible for
> numerical values (obcolor, UV, VCol), but there's no way to say "this
> object will have material X but with textures A and B".
> >
> > Also, many existing features of Blender Render are technically feasible
> in GLSL but are absent, such as having some other object for texture
> coordinates, or "blend" textures (having to use a color ramp node instead).
> Although in general this point is not important if we're planning an
> overhaul.
> >
> > Bottom line, I'm planning in developing a stand-alone GLSL-based (or
> SPIR-V or some abstraction for both) graphics engine which can be
> potentially integrated into Blender both as render engine and as viewport
> renderer.
> >
> > Cheers.
> >
> >
> >
> >
> > On Sat, Jan 9, 2016 at 2:49 PM, Ton Roosendaal <ton at blender.org> wrote:
> > Hi Brecht,
> >
> > "Vision" is a big word, it can mean a lot. Currently there's nobody with
> sufficient time to tackle the design, that's true. But such problems could
> be solved by active recruitment and/or funding.
> >
> > What I miss is a mention of using the Unreal shader design. It was
> suggested to align as close as possible to Unreal shaders for our 2.8
> viewport, and use that to make viewport previz possible for Cycles or other
> engines.
> >
> > I also miss active contributors giving feedback. It's not so much about
> ideas or visions, I want to hear what people would suggest to work on,
> however small it is.
> >
> > Alexander: there's a whole lot of open patches from you indeed. I think
> we should more seriously look into that with high priority. For as long
> things stay compatible (old files render same), we can be quite flexible
> here. Provided you're around to maintain the issues a chance causes of
> course.
> >
> > Laters,
> >
> > -Ton-
> >
> > --------------------------------------------------------
> > Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> > Chairman Blender Foundation - Producer Blender Institute
> > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >
> >
> >
> > > On 8 Jan, 2016, at 19:26, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
> > >
> > > Ok, so it seems that currently there isn't really a vision for a
> > > better realtime shading system. At least not from people reading the
> > > bf-viewport and bf-gamedev mailing lists.
> > >
> > > I'll review the patches that seem reasonable to me and don't really
> > > break compatibility, and those can go into Blender 2.77. For bigger
> > > changes someone else would need to take the responsibility.
> > >
> > > On Fri, Jan 8, 2016 at 1:48 PM,  <a.romanov at blend4web.com> wrote:
> > >>
> > >>> Adding these Cycles node features to BI seems all reasonable to me,
> > >>> particularly if the target would be to unify things more with Cycles
> > >>> material nodes instead of adding a completely new system
> > >>> specifically
> > >>> for the viewport.
> > >> It's very good, because we are primarily interested in such things.
> > >> And patches with support for BI and GLSL could even go into the 2.7
> > >> branch as it does not break backward compatibility, isn't it?
> > >>
> > >>>
> > >>> The issue with incremental changes is that you're also pretty much
> > >>> forced to incrementally break compatibility over many Blender
> > >>> versions, which is annoying for users. If it was mostly about
> > >>> parameters, just adding a new PBR material node would be a good
> > >>> solution for compatibility.
> > >>>
> > >> Primarily we are interested in the stable branch of viewport
> > >> corresponding to current state of BI. So it could be 2.7 branch with
> > >> simplified material workflow, that could be done by adding a new PBR
> > >> material node.
> > >>
> > >>> But there's issues with the way lights and materials interact, how
> > >>> transparency and ray tracing are wrong in subtle ways, distinctions
> > >>> between specular/reflection and diffuse/environment light, and more.
> > >>> In my experience keeping those exceptions while also adding a new
> > >>> PBR
> > >>> mode makes the code extremely complicated.
> > >>>
> > >>> I don't want to go into too much detail here, but here's some old
> > >>> notes about design issues if you're interested:
> > >>>
> http://wiki.blender.org/index.php/Dev:2.5/Source/ShadingSystem/Implementation
> > >>> http://wiki.blender.org/index.php/User:Brecht/RenderIdeas
> > >>>
> > >> Thanks for the tip. I need more deeply to learn.
> > >>
> > >>> Anyway, maybe it is fine to incrementally break compatibility during
> > >>> the Blender 2.8 release cycle and users will just have to accept
> > >>> that?
> > >>> Whatever way we do this, it would still be good to have some kind of
> > >>> vision for what the end result should be.
> > >> In Blend4Web we keep deprecated features in 3-5 releases and our users
> > >> have time to adjust. But we have releases per month.
> > >> It's important to understand exactly what is the aim of the first
> > >> release of 2.8. I'm also not sure I understand. But, from the
> > >> conversation it seems to me that BI should stay.
> > >>
> > >>
> > >> _______________________________________________
> > >> Bf-viewport mailing list
> > >> Bf-viewport at blender.org
> > >> http://lists.blender.org/mailman/listinfo/bf-viewport
> > > _______________________________________________
> > > Bf-gamedev mailing list
> > > Bf-gamedev at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-gamedev
> >
> > _______________________________________________
> > Bf-gamedev mailing list
> > Bf-gamedev at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-gamedev
> >
> > _______________________________________________
> > Bf-gamedev mailing list
> > Bf-gamedev at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-gamedev
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20160110/90e6ca72/attachment-0001.htm 