[Bf-committers] Bringing Freestyle back to Blender 2.8

[Ton Roosendaal]

Hi Tamito,

Please check on what the viewport is doing currently with the new dependency graph. I know we lack docs a bit, but this is where Dalai Felinto and Sergey Sharybin work on.

Simply said: the new dependency graph will generate per (view-)layer a complete independent copy of scene data, as required by the renderer that's hooked up to the layer. Not only for real time engines, also Cycles uses this (or will use it).

A render engine can get a realtime implementation (for live update in viewports), and an offline version (drawing to buffers or saving images). Freestyle could also attempt both of this. A rewrite to make it fully real-time has my preference though.

Another interesting topic is to make a dedicated real-time NPR engine for Blender. Design is now really ready for it (NPR fans, read this? No need to fork or branches. Let's work together on this in 2.8).

Holiday season is almost over. On Tuesday Dalai is back here. I'll check with him on his ideas for how to do this well. and let him connect you for it.

Thanks,

-Ton-

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

> On 10 Aug 2017, at 04:06, Tamito KAJIYAMA <rd6t-kjym at asahi-net.or.jp> wrote:
> 
> Hi Brecht,
> 
> Many thanks for the detailed replies, and excuse me for the delayed reply.
> 
> I agree that the first thing to do to keep Freestyle functional in the 
> Blender 2.8 code base is the removal of Freestyle's dependency to the 
> object/mesh data structures of the Blender Internal.  Freestyle in 
> Blender 2.7x and earlier receives a bunch of tris/quads through the 
> Render::instancetable (that is, a linked list of ObjectInstanceRen 
> data).  Freestyle doesn't really have to care about many details of 
> Blender scene data, mesh modifiers, animation, render settings, and so 
> on---instead, the ObjectInstanceRen data allow Freestyle to simply deal 
> with a final set of polygons resulting from all the rendering related 
> details already addressed by the Blender Internal and Cycles.  If there 
> is a convenient way to do the same in 2.8, then I expect the dependency 
> removal would be straightforward.  Otherwise, the work might be a bit of 
> hassle.
> 
> As to the material system, Freestyle currently relies on static (not 
> node-based) material properties such as diffuse color, specular color, 
> and some other props.  In addition, there are a few Freestyle-specific 
> static material properties such as line color, line alpha transparency, 
> and line priority (plus, line thickness is to be added in the future). 
> Freestyle employs static colors as solid line colors no matter how the 
> material is lit by various light sources and seen by the camera.  If 
> everything is defined by material nodes in 2.8, then a few extra nodes 
> specific to Freestyle are necessary.  At the moment Freestyle doesn't do 
> anything with material nodes when retrieving material props.  So, again 
> everything in nodes might imply a substantial amount of work on the 
> Freestyle side.
> 
> As far as Eevee gives Freestyle a render buffer to which line components 
> are composited, that's fine and I expect very little work there. 
> Freestyle performance is far from real time, so I would say Freestyle 
> rendering in the viewport is out of scope in short- and mid-term ranges.
> 
> Best regards,
> 
> -- 
> KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>
> 
> 
> On 2017/08/01 9:47, Brecht Van Lommel wrote:
>> Hi Tamito,
>> 
>> Blender internal and its material system have not been removed yet, but
>> they are planned to be replaced by Eevee. I don't think anyone has actually
>> gone though what that entails in detail, since there is indeed code like
>> Freestyle and the texture system that rely on it even when not rendering
>> with BI.
>> 
>> I expect the first thing to keep things functional would be to stop relying
>> on the BI object/mesh data structures, and rather get geometry directly
>> from the Blender object/mesh data structures. This should be easier now
>> than it was when Freestyle was initially implemented, since there are now
>> functions like BKE_mesh_new_from_object to get a mesh from any type of
>> object. Some of this stuff will likely still evolve some as the dependency
>> graph is being worked on.
>> 
>> Materials I think would all be defined using node graphs, which should
>> already work with Freestyle? But for NPR work is needed to get back some
>> functionality from Blender Internal. There is no design for that yet as far
>> as I know, would be interesting to get some idea which extra nodes Eevee
>> needs.
>> 
>> In terms of integrating with render buffers, I hope the way it works with
>> Cycles as an external engine can also work for Eevee. So Eevee could
>> deliver render buffers the same way as Cycles and freestyle could composite
>> on top of them in the same way. Beyond that it would of course be really
>> cool if Freestyle could work in realtime on top of Eevee, showing OpenGL
>> accelerated line drawing in the viewport, but I guess that would be almost
>> a full rewrite of Freestyle.
>> 
>> Regards,
>> Brecht.
>> 
>> 
>> On Mon, Jul 31, 2017 at 4:26 PM, Tamito KAJIYAMA <rd6t-kjym at asahi-net.or.jp>
>> wrote:
>> 
>>> Hi,
>>> 
>>> I would like to discuss with the viewport team what precisely would be
>>> necessary to bring Freestyle back to Blender 2.8.  I was informed that
>>> the old material system and the Blender Internal renderer have been
>>> removed so that Freestyle won't work anymore.  The idea is to have a
>>> development plan of what needs to be done and until when.  Thoughts and
>>> suggestions are much welcome.  Thanks in advance for the input.
>>> 
>>> Best regards,
>>> 
>>> --
>>> KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers