[Bf-cycles] Bevel shader

Ilja Razinkov razinkov at gmail.com
Fri Aug 18 13:16:48 CEST 2017


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
>



-- 
с уважением, Разинков Илья


More information about the Bf-cycles mailing list