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