Bringing Freestyle back to Blender 2.8

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bringing Freestyle back to Blender 2.8

Tamito Kajiyama
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 <[hidden email]>
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Freestyle back to Blender 2.8

Brecht Van Lommel
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 <[hidden email]>
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 <[hidden email]>
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Freestyle back to Blender 2.8

Tamito Kajiyama
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 <[hidden email]>


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 <[hidden email]>
> 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 <[hidden email]>
>> _______________________________________________
>> Bf-committers mailing list
>> [hidden email]
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Freestyle back to Blender 2.8

Brecht Van Lommel
Regarding relying on static material properties, I think those can be kept
then. The diffuse/specular/hardness could be moved into the Freestyle Line
panel and only used by Freestyle.

On Thu, Aug 10, 2017 at 4:06 AM, Tamito KAJIYAMA <[hidden email]>
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 <[hidden email]>
>
>
> 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 <
> [hidden email]>
> > 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 <[hidden email]>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> [hidden email]
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > [hidden email]
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Freestyle back to Blender 2.8

Jacob Merrill
many people are using cell shading in realtime to produce cartoon  renders
in real time, maybe this could be a path to realtime npr?

also, I seem to recall a geometry shader produce can outline almost
instantly?



On Aug 12, 2017 5:54 AM, "Brecht Van Lommel" <[hidden email]>
wrote:

> Regarding relying on static material properties, I think those can be kept
> then. The diffuse/specular/hardness could be moved into the Freestyle Line
> panel and only used by Freestyle.
>
> On Thu, Aug 10, 2017 at 4:06 AM, Tamito KAJIYAMA <
> [hidden email]>
> 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 <[hidden email]>
> >
> >
> > 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 <
> > [hidden email]>
> > > 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 <[hidden email]>
> > >> _______________________________________________
> > >> Bf-committers mailing list
> > >> [hidden email]
> > >> https://lists.blender.org/mailman/listinfo/bf-committers
> > >>
> > > _______________________________________________
> > > Bf-committers mailing list
> > > [hidden email]
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > [hidden email]
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bringing Freestyle back to Blender 2.8

Ton Roosendaal
In reply to this post by Tamito Kajiyama
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  -  [hidden email]   -   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 <[hidden email]> 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 <[hidden email]>
>
>
> 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 <[hidden email]>
>> 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 <[hidden email]>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> [hidden email]
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> [hidden email]
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> [hidden email]
> https://lists.blender.org/mailman/listinfo/bf-committers

_______________________________________________
Bf-committers mailing list
[hidden email]
https://lists.blender.org/mailman/listinfo/bf-committers
Loading...