From stewreo at gmail.com Thu Sep 7 08:18:23 2017 From: stewreo at gmail.com (Stefan Werner) Date: Thu, 7 Sep 2017 08:18:23 +0200 Subject: [Bf-cycles] ccl::array == operator Message-ID: <2A2EACC9-C025-4347-9118-B38F49896BF3@gmail.com> Hello, when tracing an odd bug in some code I?m working on*, I noticed something in ccl::array. The == operator for the array uses memcmp() to test two arrays for equality, as opposed to an element by element == compare which std::array::== is using. Using memcmp() for a comparison of classes or structs is not guaranteed to work and can return false negatives. This can cause subtle bugs which may not be obvious at first. In my case, it was comparing two arrays of structs, of which all elements are equal. However, since the compiler added padding for alignment, there were undefined bytes in between struct members, causing memcmp() to fail. This padding is not visible in your average debugger, only once you inspect raw memory you do see what?s at odds there. I noticed that in Cycles we?re using ccl::array::== on some arrays where it is not guaranteed to work. Prime candidate is using it in Node::equals_value(), where it is applied to arrays of OIIO::ustring - using memcmp() on 3rd party C++ classes is likely to break, if not today, then at some point in the future. I?m also worried about using it for float3 types, which internally are float4s with the 4th float being undefined. Note that in case where Node::equals_value() is comparing single elements that are not arrays, it is also doing memcmp() on ustrings instead of using ustring::==. I have no direct bug in master/HEAD that is caused by this behaviour, but a failing ccl::array::== operator caused problems in my custom code. As far as I can see from here, the main use of it seems to be the optimisation of shader graphs, where false negatives would prevent possible optimisations from happening. My proposal would be to replace ccl::array::== with an element-by-element comparison as in std::array::==, with template specialisations for hand picked cases where memcmp() is known to be safe (these may be compiler and architecture specific). This will slow down some things, but I prefer slow and correct code over fast and broken. Since it?s code that, to my knowledge, we?re not using inside the path tracing kernel, performance penalties should not be too painful. -Stefan * A version of Lukas? AOV patch used for Cryptomatte, hopefully coming soon to a differential on d.b.o. From alberto3d.1984 at gmail.com Thu Sep 7 11:14:17 2017 From: alberto3d.1984 at gmail.com (=?UTF-8?Q?Alberto_Vel=C3=A1zquez?=) Date: Thu, 7 Sep 2017 11:14:17 +0200 Subject: [Bf-cycles] Bevel shader In-Reply-To: References:

<4E46FA92-6009-4306-AAC6-3583EB9AC19F@gmail.com>

<85C9EB1D-29DB-40B7-BCB9-206187F60848@gmail.com>

Message-ID: Any news about this patch? some people, included me, are waiting a confirm patch to use this blender feature in production. 2017-08-21 0:20 GMT+02:00 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 : >> >>> 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 >> >: >>> >>>> 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 >>>> 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 >>>>>>> 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 >> >> > > _______________________________________________ > 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: From brechtvanlommel at pandora.be Tue Sep 12 16:31:14 2017 From: brechtvanlommel at pandora.be (Brecht Van Lommel) Date: Tue, 12 Sep 2017 16:31:14 +0200 Subject: [Bf-cycles] ccl::array == operator In-Reply-To: <2A2EACC9-C025-4347-9118-B38F49896BF3@gmail.com> References: <2A2EACC9-C025-4347-9118-B38F49896BF3@gmail.com> Message-ID: Doing element by element comparison is fine with me, I'm not concerned about performance here. On Thu, Sep 7, 2017 at 8:18 AM, Stefan Werner wrote: > Hello, > > when tracing an odd bug in some code I?m working on*, I noticed something > in ccl::array. The == operator for the array uses memcmp() to test two > arrays for equality, as opposed to an element by element == compare which > std::array::== is using. Using memcmp() for a comparison of classes or > structs is not guaranteed to work and can return false negatives. This can > cause subtle bugs which may not be obvious at first. > > In my case, it was comparing two arrays of structs, of which all elements > are equal. However, since the compiler added padding for alignment, there > were undefined bytes in between struct members, causing memcmp() to fail. > This padding is not visible in your average debugger, only once you inspect > raw memory you do see what?s at odds there. > > I noticed that in Cycles we?re using ccl::array::== on some arrays where > it is not guaranteed to work. Prime candidate is using it in > Node::equals_value(), where it is applied to arrays of OIIO::ustring - > using memcmp() on 3rd party C++ classes is likely to break, if not today, > then at some point in the future. I?m also worried about using it for > float3 types, which internally are float4s with the 4th float being > undefined. > > Note that in case where Node::equals_value() is comparing single elements > that are not arrays, it is also doing memcmp() on ustrings instead of using > ustring::==. > > I have no direct bug in master/HEAD that is caused by this behaviour, but > a failing ccl::array::== operator caused problems in my custom code. As far > as I can see from here, the main use of it seems to be the optimisation of > shader graphs, where false negatives would prevent possible optimisations > from happening. > > My proposal would be to replace ccl::array::== with an element-by-element > comparison as in std::array::==, with template specialisations for hand > picked cases where memcmp() is known to be safe (these may be compiler and > architecture specific). This will slow down some things, but I prefer slow > and correct code over fast and broken. Since it?s code that, to my > knowledge, we?re not using inside the path tracing kernel, performance > penalties should not be too painful. > > -Stefan > > * A version of Lukas? AOV patch used for Cryptomatte, hopefully coming > soon to a differential on d.b.o. > _______________________________________________ > 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: