[Bf-blender-npr] BEER: a possible action plan and request for comments/feedback.

[Khalifa Lame]

If the new GLSL system will allow for blending of custom shaders and
textures as well as a UI for parameters (uniform variables) like in Unity
3D for example, then that should go a very long way. That's essentially
what BEER materials are in a nutshell --blended shaders.

Also, if the opengl renderer was made to be more flexible and more
powerful, then I suppose BEER wouldn't need to be a separate project after
all. Currently, the opengl renderer is tied blindly to the viewport and
that would need to change in order for it to be able to take full advantage
of opengl's capabilities and for other renderers such as BEER to be able to
build on top of it.

On Mon, Nov 3, 2014 at 1:24 PM, Antony Riakiotakis <kalast at gmail.com> wrote:

> Hi,
>
> A few things about the current state of the viewport project and how it
> might relate to the beer project.
>
> Basically, the GSOC projects tackled real time drawing centralization
> under a single module,
> so it has to do with viewport performance and architecture mostly.
> The part I have been doing the past few weeks is basically real time
> compositing on top of the viewport.
>
> The use of the viewport project in rendering is a target I am considering
> - basically it is already quasi-possible with the OpenGL render
> functionality, but of course the current system tries to duplicate what
> blender internal does during rendering.
>
> What you want to do is basically a new renderer. Your node system is
> completely different than blender internal's. At that point you have to
> know if you want this to be a GPU renderer, which will interact closely
> with what OpenGL can do, or make a CPU renderer with a node interface.
> GPUs basically don't allow everything the CPU does (such as ray traced
> shadows and refractions for instance) and you will have to code it.
>
> I could help by making the viewport flexible enough to facilitate easy
> real time drawing by other engines - if possible. We already have a target
> to make a separate node tree for GLSL materials which should allow custom
> GLSL code. I am not sure if the shader system we will use will coincide
> with what you have in mind. Personally I was inclined towards something
> more PBR based, which is oriented to game asset creation mostly, while your
> own system looks more geared towards npr rendering. Also it looks like a
> mixture of compositing and real time preview, which requires a tight
> integration with the viewport - tighter than we will be able to provide
> probably.
>
> Like Ton, I don't think having a separate project is a bad idea. I am open
> to help in designing the viewport to be more flexible to help with what you
> want to do if possible but I need to see a design or system requirements
> document from a developer - what data is needed where, what the system is
> expected to do, what the GPU is expected to handle. What I have seen so far
> looks more like a limited use case document. If you are serious about this
> you should provide more details. What is it expected to render, how it will
> work with compositing, what is expected to be real time, what will be
> nodified. Unfortunately I can't make those decisions for you, so you
> really, really need a coder who understands these things, and preferably
> blender's code base as well. And if your vision and what blender can do
> can't match easily maybe you could consider a separate project, or even a
> fork? I don't say that to be negative at all, but the project sounds
> different enough that you might want to explore that possibility.
>
> _______________________________________________
> Bf-blender-npr mailing list
> Bf-blender-npr at blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-npr
>
>


-- 
khalibloo®
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-blender-npr/attachments/20141103/77063a0a/attachment.htm