[Bf-viewport] Welcome to the viewport list!

[Ton Roosendaal]

Hi all,

I've added Antonis R, Jason W, Mike E, Alexandr K and myself on the list now.
There's a need for a more central place to discuss work and design ideas for the Viewport.

As a starter, I've added a mail from Antonis below again, which he sent out late last year to everyone.

My goal would be to:

- (re)confirm design, the big picture but also API details
- make a roadmap or planning
- cut work in feasible and fun (inviting for users too) sections

Everyone is welcome on the list of course, but the focus is to get things done! 

Thanks,

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands


Hi everyone,

So, just published a high level overview of the state of the project in the code blog:

http://code.blender.org/index.php/2014/12/future-viewport-the-design/

We are trying to focus on getting functionality in master, so we have two options:

Either merge the viewport branch as soon as possible and cleanup as needed, or just focus on the targets we want to achieve and keep the target architecture low (no GL 3.2 core, no mobile support).

I would like to allocate some work to everyone and know if they will be available in the near future.

The work we need is as follows:

-----------------------------------------------------

1) A batch manager. 

This includes a material/shader sorting engine and a data request system for shaders. A shader should be able to request a specific kind of data from an object and the mesh object should be able to generate it, with faces sorted by material if needed to allow easy sorting of mesh instances in the renderer. This will be the core of the new system and possibly the most important aspect of the new viewport design. Also it's a big target that touches all of the object rendering code, also derivedmesh code. Probably after the core system has been written, all draw paths will have to be re-written to use it.

2) Merge the soc-2013/4-viewport_fx project

This is self explanatory. The branch was supposed to be merged in parts but this can make reviewing more tedious. I suggest there is one patch, which includes most of the code that -works- in soc-2013-paint. After that we can change and cleanup blender code to use the included in the branch API better. There is a part of the patch that adds lots of redefinitions which I found a bit overkill, but at this point I think we can refine this further when the patch is in blender, and depending on other factors (mainly if there is someone who is willing to ensure the project is compatible with the mobile target).

3) GLSL node/GLSL renderer node tree.

This sounds scary, but for now we can just add GLSL specific BSDF-like shaders, reuse the existing node shaders and write a special GLSL node.
That node will act similarly to the OSL node, basically you will be able to attach a tet file with GLSL code in it. The GLSL code will need a function with a predefined name, which will be parsed for -in and -out variables and sockets will be created in the node accordingly. Then users should be able to write their own shaders to drive real time display. The system will be able to request data from the meshes using the batch manager outlined in 1) based on the inputs the user will plug into this shader. Those inputs will be used to request mesh data during node tree compilation.

4) Make sure all this is compatible for the mobile platform if possible

This requires collaboration with somebody who knows GLES well enough so we keep code working on all platforms, but first we need to have a working blender in mobile. Someone who can help with this is more than welcome. Merging the soc branch will surely help here.

5) Work on "workflow" modes.

Workflow is basically a way of drawing that is tied to a task. In blender we don't call them workflows currently, rather we have lots and lots of conditionals in the derivedmesh level to change drawing slightly, according to the object mode. This should be shader-ified in the new viewport so a workflow shader such as the one used in vertex painting, will just request vertex weight data and do its thing.
This target is a part of 1) and also sounds similar to the aspect system in the soc branch, but whether the aspect system can be reused here is to be decided.

--------------------------------------------------------------------

Mike has expressed interest in working with the batch manager.

It would help tremendously if Jason and/or Alex can help migrating the soc-viewport branch.
in the next 2-3 months (accounting for Christmas/new year or exams). I know this depends on your free time, so I don't want to push too much here, but if you can't help, it would still help to know so we can make a decision whether to let someone else do it or skip it.

I am still preoccupied with the gooseberry targets but as soon as I have time I will probably be helping with the batch or node code.


So to recap:

Jason and Alexander try to merge the soc branch (unless they want to help elsewhere or don't have time, in which case it would help to know)

Me and Mike work on the batch manager - I will be contacting you very soon on that.