[Bf-committers] Bringing Freestyle back to Blender 2.8

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Aug 12 14:53:56 CEST 2017


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 <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
>


More information about the Bf-committers mailing list