[Bf-cycles] Bevel shader

[Ilja Razinkov]

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
>



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