[Bf-cycles] Bevel shader

Alberto Velázquez alberto3d.1984 at gmail.com
Fri Aug 18 09:40:19 CEST 2017


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20170818/c91a7c6e/attachment.html>


More information about the Bf-cycles mailing list