[Bf-cycles] Bevel shader

Alberto Velázquez alberto3d.1984 at gmail.com
Fri Aug 18 13:31:07 CEST 2017


With speed I talk about speed if you compare with normal CPU render, not
compared with GPU. The OSL Bevel shader is 5-10 render times longer that
normal CPU render.

2017-08-18 13:16 GMT+02:00 Ilja Razinkov <razinkov at gmail.com>:

> CPU speed is indeed a problem, but IMHO other issues can be overcome
> with proper attention - complexity, "didn`t work", etc.
> Baking itself is more general area of interest, so generalized
> solution can give even more usefulness for Blender users
>
> On Fri, Aug 18, 2017 at 10:40 AM, Alberto Velázquez
> <alberto3d.1984 at gmail.com> wrote:
> > Actually we have a workaround to try bevels with OSL, but it don't work
> > properly, it's really slow (x5-10 times in render time from CPU) and it
> is
> > really complex to use. And It's worst baking.
> >
> > 2017-08-18 7:35 GMT+02:00 Ilja Razinkov <razinkov at gmail.com>:
> >>
> >> Just a suggestion: Add explicit OSL support to baking procedure, so
> >> anyone will be able to write thier own shader! Looks like such bake
> >> can be written in OSL in minutes
> >>
> >> On Thu, Aug 17, 2017 at 10:15 PM, Alberto Velázquez
> >> <alberto3d.1984 at gmail.com> wrote:
> >> > Actually this tool is the more voted in rightselectclick and all
> artists
> >> > will be really grateful to the developer that make it possible. And
> It's
> >> > important, right now that Vray have implemented it.
> >> >
> >> > I don't want mess the coder thread. From an artist pov the "even
> across
> >> > meshes that are not connected" could be dangerous if this can not be
> >> > optional or if this creates artifacts in near meshes that not
> intersect
> >> > and
> >> > only are inside the radius of bevel (for example two planes amost
> >> > parallels).
> >> >
> >> > Warm regards
> >> >
> >> > 2017-08-17 10:51 GMT+02:00 Brecht Van Lommel
> >> > <brechtvanlommel at pandora.be>:
> >> >>
> >> >> If anyone is interested in implementing this, a ray tracing based
> >> >> solution
> >> >> is probably most flexible since it will work regardless of topology
> and
> >> >> even
> >> >> across meshes that are not actually connected. You could randomly
> >> >> sample
> >> >> e.g. 4 points on surrounding geometry and compute a normal using a
> >> >> weighted
> >> >> average of the normals at those points. It's similar to subsurface
> >> >> scattering, maybe could share some ray tracing code and use the same
> >> >> MIS
> >> >> mechanism to combine samples along the XYZ axes.
> >> >>
> >> >> Like ambient occlusion color output, the tricky part here is that so
> >> >> far
> >> >> we haven't done any raytracing from inside shaders. Adding the ray
> >> >> tracing
> >> >> calls to the shader evaluation could have quite bad effects on GPU
> >> >> performance. But maybe it's also not actually a problem, needs to be
> >> >> tested.
> >> >> If really needed the ray tracing could be done before the shader
> >> >> evaluation,
> >> >> but that would probably make it impossible to control the shader
> >> >> parameters
> >> >> with other shaders or have multiple AO / bevel shaders with different
> >> >> parameters in the same material.
> >> >>
> >> >>
> >> >> On Thu, Aug 17, 2017 at 1:54 AM, Brecht Van Lommel
> >> >> <brechtvanlommel at pandora.be> wrote:
> >> >>>
> >> >>> Forwarding a message from DcVertice on blenderartists, since it
> seems
> >> >>> to
> >> >>> be stuck in the bf-cycles moderation queue:
> >> >>>
> >> >>>> After talk with bretch I want to show why artists need a round
> edges,
> >> >>>> and why it's so important for all game artist community. Of course
> >> >>>> that
> >> >>>> bevel modifier is a solution when you want only bake high poly, but
> >> >>>> have
> >> >>>> some limitations and the pipeline of work change drastically with
> the
> >> >>>> round
> >> >>>> edges and could reduce the work load of an artist in days
> >> >>>> (literally).
> >> >>>>
> >> >>>> First I want to show the ways to bake a bevel (A basic work in hard
> >> >>>> surfaces) actually.
> >> >>>>
> >> >>>> http://pasteall.org/pic/show.php?id=118028
> >> >>>>
> >> >>>>
> >> >>>> Like you see all methods have different solutions.
> >> >>>>
> >> >>>> The first solution is use the same mesh shape with normals splited.
> >> >>>> It's
> >> >>>> unusable and nobody can use this, the results are no acceptable.
> >> >>>> The second solution is adapt the mesh shape to avoid the result of
> >> >>>> the
> >> >>>> first solution. It's the best way to obtain high quality normal
> maps,
> >> >>>> but
> >> >>>> the work to make complex shapes increment a lot.
> >> >>>> The third solution is use the same mesh but with average or custom
> >> >>>> normals. It creates gradients and distorsion the mesh details (like
> >> >>>> pipes,
> >> >>>> screws,...). The gradient is a big problem in games because with
> >> >>>> texture
> >> >>>> compresion result in a lot of artifacts and must be avoid. I'm sure
> >> >>>> that if
> >> >>>> you like games you will have seen artifacts in normal maps in hard
> >> >>>> surfaces
> >> >>>> objects.
> >> >>>>
> >> >>>>
> >> >>>> We could create a cage for projection, but in AAA models it means a
> >> >>>> lot
> >> >>>> of work, problems, distorsion of details, conflicts in the box,...
> In
> >> >>>> efficence is the worst solution, with difference and I don't
> consider
> >> >>>> talk
> >> >>>> about it. making the distorsions a constant.
> >> >>>>
> >> >>>> http://pasteall.org/pic/show.php?id=118029
> >> >>>>
> >> >>>> All the solutions also have a basic problem, errors in projection
> of
> >> >>>> near geometry, cleaning time,.... At the end if we want make real
> >> >>>> production
> >> >>>> quality game assets we only can consider the second solution.
> Anyway
> >> >>>> It's a
> >> >>>> destructive pipeline (you must have a low poly mesh with different
> >> >>>> shape of
> >> >>>> the high poly) and each change means that the artist need to make
> the
> >> >>>> double
> >> >>>> of changes and test if it works. In video games it's not strange
> that
> >> >>>> a game
> >> >>>> model have a lot of feedback, 3 or 4 times, or even more, with a
> lot
> >> >>>> of
> >> >>>> changes. In a box, move the vertex is something easy, now think in
> a
> >> >>>> production model....
> >> >>>>
> >> >>>> http://pasteall.org/pic/show.php?id=118030
> >> >>>>
> >> >>>> To make the same in all sites to obtain high quality results this
> >> >>>> model
> >> >>>> could need days of works to make a correct bake, and depeding of
> >> >>>> feedback
> >> >>>> any change will need other day. A round shader solution would be a
> >> >>>> magical
> >> >>>> solution for all the problems, or at least the 80% of baking.
> Making
> >> >>>> a
> >> >>>> pipeline no-destructible friendly, and one artist could reduce the
> >> >>>> time to
> >> >>>> bake this to hours. We talk to cut out days of work. And maybe
> reduce
> >> >>>> the
> >> >>>> total time to create a model in a 30% in the best case, but maybe a
> >> >>>> 50-60%
> >> >>>> or reduction for the future changes that feedback impose.
> >> >>>>
> >> >>>> Other cases where a round edge shader will be a kill feature is the
> >> >>>> baking of bevels for cylinders and similar topology that actually
> >> >>>> needs a
> >> >>>> custom aproximation to the problem that needs a lot of parts and
> >> >>>> actually is
> >> >>>> the worst case scenary that a artist can find. With this shader all
> >> >>>> this
> >> >>>> will be automatic.
> >> >>>>
> >> >>>> Also the round edge shader is not only good for baking for game
> >> >>>> artist,
> >> >>>> it's also good to cycles rendering because bevel destroy the UVs
> and
> >> >>>> the
> >> >>>> artist needs to collapse the model, make new uvs,... and with this
> >> >>>> tool the
> >> >>>> artist doesn't need to redo the UVs, or use a destructible
> pipeline.
> >> >>>>
> >> >>>> Like artist I can confirm strongly that this round edge shader for
> >> >>>> baking and cycles is a top feature that will change all the
> pipeline
> >> >>>> of all
> >> >>>> 3d artist that use blender. Reducing the production times in days,
> >> >>>> making
> >> >>>> the feedback less painful and also making Blender more referent for
> >> >>>> game
> >> >>>> artists.
> >> >>>>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Bf-cycles mailing list
> >> >> Bf-cycles at blender.org
> >> >> https://lists.blender.org/mailman/listinfo/bf-cycles
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Bf-cycles mailing list
> >> > Bf-cycles at blender.org
> >> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >> >
> >>
> >>
> >>
> >> --
> >> с уважением, Разинков Илья
> >> _______________________________________________
> >> Bf-cycles mailing list
> >> Bf-cycles at blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
>
>
>
> --
> с уважением, Разинков Илья
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20170818/e75301e4/attachment.html>


More information about the Bf-cycles mailing list