[Bf-cycles] Bevel shader

[Brecht Van Lommel]

Baking should work now with the latest patch and commits in master.

Still a problem is that normal baking does not use AA samples, which then
requires using very high samples in the bevel shader, which is bad for
regular renders.

On Sun, Aug 20, 2017 at 8:03 PM, Alberto Velázquez <alberto3d.1984 at gmail.com
> wrote:

> Hi
>
> Brecht, I don't know if you thought in this in your idea of implementation
> but It's wonderfull. I didn't think in that. With the implementation that
> you made now a user can "paint" normal maps panels only adding geometry
> near to the object. The tool now is double ground breaking.
>
> http://i.imgur.com/Evyasjv.png
>
> Warm Regards
>
> 2017-08-20 19:02 GMT+02:00 Alberto Velázquez <alberto3d.1984 at gmail.com>:
>
>> Hi
>>
>> I have tried the shader in a really complex project (before bevel
>> modifier workflow) and the result is very good. The model that originally
>> needs 180k tris (1,4 with subdivision) only needs now 30k, and could be
>> better. The render time was in a laptop 4 minutes at 1080p, a good time
>> with 12 samples.
>>
>> I didn't see any problem except that in a model with bad scale the shader
>> made strange shapes, but with apply scale was enough to solve.
>>
>> http://pasteall.org/pic/show.php?id=118135
>>
>> warm regards
>>
>> 2017-08-20 16:58 GMT+02:00 Brecht Van Lommel <brechtvanlommel at pandora.be>
>> :
>>
>>> It's difficult to do that for arbitrary mesh topology. I haven't thought
>>> about it too deeply, but some problems:
>>>
>>> * There can be other triangles between the current triangle and the edge
>>> to be beveled, making computing the distance difficult.
>>> * The normal interpolation would need to be non-linear in some way that
>>> I'm not sure is easy to do smoothly across neighboring triangles.
>>> * There can be more beveled corners nearby than you can capture with
>>> vertex/edge attributes, for example near the middle of an edge.
>>>
>>> Besides that, raytracing works across disconnected components which
>>> seems to be a feature that users want.
>>>
>>>
>>> On Sun, Aug 20, 2017 at 12:35 PM, Stefan Werner <stewreo at gmail.com>
>>> wrote:
>>>
>>>> Maybe I’m overlooking something, but why is ray tracing necessary for
>>>> beveled edges? Wouldn’t it be more accurate and quicker to store per-face,
>>>> per-vertex and per-edge normals and blend between them based on the current
>>>> point’s distance to the nearest edge and vertex?
>>>>
>>>> -Stefan
>>>>
>>>> On 20. Aug 2017, at 11:17, Brecht Van Lommel <
>>>> brechtvanlommel at pandora.be> wrote:
>>>>
>>>> There is no support for baking this yet, there's a bunch of issues to
>>>> resolve for that still.
>>>>
>>>> On Sun, Aug 20, 2017 at 2:42 AM, Alberto Velázquez <
>>>> alberto3d.1984 at gmail.com> wrote:
>>>>
>>>>> WOW, It works really great and speedy that OSL solution. It's really
>>>>> exciting. Which is the workflow to bake it?
>>>>>
>>>>> warm regards
>>>>>
>>>>> 2017-08-20 1:55 GMT+02:00 Brecht Van Lommel <
>>>>> brechtvanlommel at pandora.be>:
>>>>>
>>>>>> Here's a patch for a bevel shader node:
>>>>>> https://developer.blender.org/D2803
>>>>>>
>>>>>> It's using a raytraced sampling algorithm that's different than other
>>>>>> rounded edge implementations I've heard of, derived from BSSRDF sampling.
>>>>>>
>>>>>> On Fri, Aug 18, 2017 at 2:11 PM, Stefan Werner <stewreo at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> > On 18. Aug 2017, at 09:40, 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.
>>>>>>>
>>>>>>> Without having tried it, I wouldn’t expect much better performance
>>>>>>> without OSL. A rounded edge shader requires tracing several extra rays,
>>>>>>> which are costly regardless of the shader language.
>>>>>>>
>>>>>>> If anyone wants to try their luck implementing it directly in
>>>>>>> Cycles, these modifications made by Chaos Group could be helpful:
>>>>>>> http://on-demand.gputechconf.com/gtc/2016/presentation/s6345
>>>>>>> -taskov-blagovest-advances-in-v-ray.pdf
>>>>>>>
>>>>>>> -Stefan
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20170821/71824ed2/attachment.html>