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

Tue Nov 4 08:40:27 CET 2014

Antony,

Thanks for your reply, I really appreciate this. Currently we are at a
crossroad of options which I will state below. Because of this I cannot
answer your question easily but that does not mean we can not state what we
want in your current viewport project. And to be precise I find your work
yummie atm and very needed by many. If you look at our paper I understand
your feeling, you are more whishing for something like a technical design
which we do not have at this moment. Still there are some simple factors
that govern our choices to be made, they are:

- speed / flexible=> refering to rendering and its way of adressing
seperate components (diffuse/ao/specular)
- expandable => how easy is it to create a new shader
- workflow => ui / wysiwig

There is currently a regard of internal or external but a lot can be
achieved within Blender itself. A list of possibilities current under
review.

A) BI gets new shaders regarding to Beer concept but we leave the
flexibility and workflow out. Expandability should be included, so creating
new shaders would be no problem. This actually means programming in C. We
have no documentation on how to do this and do not know if we get into
problems later on. Regarding to Ton's email I got the feeling that Ton does
not have the time for this which I understand.

B) BI gets a GLSL shader/node which can be programmable. Thats was also
referred to by Roberto. Is more difficult to achieve (refering to the
Brecht documents) but this will adress the flexibilty and expandibilty.
Speed is a question at this stage but you can get the best of both worlds
and have freestyle already integrated. Afcourse ui maybe far off from what
we want but wysiwyg should be no problem at all.

C) Make OpenGL render a full render. Its already in Blender only not in the
standard menu and you can not use nodes etc. Still a very viabel option and
in regard what you are writing a smart way to go as well. Going PBR should
not be the biggest problem, it counts for the usage of the combine pass.
The more we can switch on/off stuff at GLSL level (and ui) the more it
suits our needs.If specularity or reflection can be a programmable 'option'
I strongly believe that the people from the gaming community do not mind
and our goals coincide.

D) Using python and optional an external library for opengl to create an
external renderer. We either use what is already in Blender (bgl) or we use
an external library (which may not crash Blender) for exporting scene
output to it. The ui is gonna be programmed in native Blender Python. If we
could use an external Python module within Blender to send output to an
opengl library we could create the shaders we need. Opengl versions are not
a problem, viewport still is. Maybe thats is more what you and Ton are
referring too, to do it like Luxrender. The render and the wysiwig viewport
is outside Blender as an external programm and data is parsed through
files. Is possible but not our current intention.

E) Make a fork for Blender. This can be done in seperate ways, most project
members are in favor for this option. There is already a fork which
incorporates the PyQt module. This addresses a lot of our needs on all
aspects regarding the usage of opengl. Qt is an ui library which gives a
lot of freedom and as I am not mistake is used in Maya (not that it matters
for this discussion). Another option could still be to create a glsl render
of our own as a third renderer by programming into c. In fact more or less
the same as option C from above. We are fully aware that a fork is not that
easy to maintain but that depends on how difficult it is to incorporate our
code.

I hope this will be less vague. Problem is we are at the investigating
stage but a lot of it all depends on the direction Blender is going with
the viewport project. Its not only the viewport alone but getting enough
access at shader level too do the stuff we want (aka combine pass should be
flexible). In that way PBR and NPR have no problems to be incorporated into
Blender natively.

Kind regards,

Wasili

2014-11-03 23:53 GMT+01:00 Khalifa Lame <khalibloo at gmail.com>:

> 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®
>
>
> _______________________________________________
> Bf-blender-npr mailing list
> Bf-blender-npr at blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-npr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-blender-npr/attachments/20141104/10dcf2a8/attachment-0001.htm 