[Soc-2017-dev] Weekly Report #01 - Normal Editing Tools

Mon Jul 17 18:50:06 CEST 2017

Sure :)
Adding a new layer to faces does seem nice.. I'll discuss with Campbell.
Also, a suggestion from BA, should I make the loop normals currently being
edited be drawn in a different colour or some visual effect while its
transforming?

On Mon, Jul 17, 2017 at 9:31 PM, Bastien Montagne <montagne29 at wanadoo.fr>
wrote:

> Hey Rohan,
>
> Can you please send that kind of mails to GSoC ML (same you use for your
> reports)? There’s really no reason to keep that kind of discussion private!
>
> Further more, Campbell's input here would be much usefull I think (think
> simplest way to go would be to add a mere 'weighted normals' new CD layer
> to faces - but really could use his advice on it).
>
> Sending to the list, please keep the discussion on it now ;)
>
> Cheers,
> Bastien
>
> Le 17/07/2017 à 17:54, Rohan Rathi a écrit :
>
> Hey,
> I'm thinking about my approach to a weighted normals modifier and I'd like
> some help. I'm thinking of adding weights for each face in the modifer, to
> set how much the face influences the normal (along side the modes). I'm not
> quite sure how to implement this.
> I guess we could use vertex groups, though its a tedious approach imo.
> Maybe spending some time on IRC to properly discuss the approach would be
> nice.
>
> Thank you
>
> On Mon, Jul 3, 2017 at 2:09 PM, Bastien Montagne <montagne29 at wanadoo.fr>
> wrote:
>
>> Hi Rohan,
>>
>> > One thing that's bugging me nowadays is that I want to add a poll
>> exclusively for checking if Auto Smooth is ON and normals exist. For each
>> op writing the same piece of code that reports error(AutoSmooth off) isn't
>> fair in my mind.
>>
>> Yep, agree, generic poll function would be nice here.
>> Le 30/06/2017 à 21:11, Rohan Rathi a écrit :
>>
>> Thanks for the feedback. I've implemented split and merge as you
>> suggested. Keeping the flags same makes a lot of sense. I'll see to it. As
>> for extend selection invalidating lnor spaces, it's a mistake on my part. I
>> thought I was thorough with adding invalidate to ops. I guess I've made a
>> few mistakes here and there. Will fix ASAP.
>>
>> One thing that's bugging me nowadays is that I want to add a poll
>> exclusively for checking if Auto Smooth is ON and normals exist. For each
>> op writing the same piece of code that reports error(AutoSmooth off) isn't
>> fair in my mind.
>>
>> On Tue, Jun 27, 2017 at 7:30 PM, Bastien Montagne <montagne29 at wanadoo.fr>
>> wrote:
>>
>>> Hi Rohan,
>>>
>>> And sorry for delay in answers… :/
>>>
>>> Not sure where you are now re merging clnors?
>>>
>>> We could go the complicated way, but in fact… I think it’s as simple as
>>> removing sharp edges between loops which you want to merge normals. Indeed,
>>> if user uses smaller AutoSmooth angle, this will not work with all normals
>>> - but someone editing its normals should always use 180° angle here!
>>> Non-manifold edges and border edges are also always considered as sharp
>>> (i.e. split of clnors), but this also not negociable nor editable.
>>>
>>> Which only leaves us with sharp edges. So process could merely be:
>>> * (optional) compute new value of merged normals.
>>> * check edges between merged normals, and remove sharp ones.
>>> * recompute lnor spaces.
>>> * (optional) set previously new value for merged normals.
>>>
>>> Same goes for spliting normals btw, just add sharp edges in-between
>>> split clnors, and you are done.
>>>
>>> ------------
>>>
>>> Now, have checked quickly your branch today, looks good generally (did
>>> very quick skimming over the code, obviously not in-depth detailed review
>>> ;) ).
>>>
>>> BMesh Operators tagging clnors as invalid: I’d suggest to add the
>>> clnor_invalid flag to the normal_invalid one (it is very, very unlikely to
>>> find a case where you need to recompute normals, but not lnor spaces ;) ),
>>> that way you avoid having to add explicitely clnor_invalidate flag to a
>>> bunch of ops already. Also, was wondering why operators like 'extend
>>> selection' need to invalidate lnor spaces?
>>>
>>> ------------
>>>
>>> Finally, I’d really like to see a short video demo of what’s you have
>>> done so far, it’s important to attract testers as soon as possible. It’s
>>> not a big deal, just one or two minutes of screen capture of Blender while
>>> you demo tools already implemented on a cool model (or our monkey's head
>>> even). Should take you half a day to create at worst. Put that on youtube,
>>> link to it in a few forums, and you'll see. :)
>>>
>>> Keep up the good work,
>>> Cheers,
>>> Bastien
>>> Le 24/06/2017 à 16:58, Rohan Rathi a écrit :
>>>
>>> Hey,
>>> I've added the ability to edit single clnors by multiple selection. I've
>>> added vert then edge selection as well, but its a bit vague as a vert, edge
>>> pair can be mapped to 2 loops. I'm not quite sure about whether to remove
>>> it.
>>>
>>> Also, I dont exactly know how to tackle merging loop normals.
>>> Any guidance appreciated! :)
>>>
>>> On Mon, Jun 12, 2017 at 12:24 PM, Bastien Montagne <
>>> montagne29 at wanadoo.fr> wrote:
>>>
>>>> Yes, definitively think invalidation is also needed for transform ops,
>>>> just moving a single vertex can invalidate a bunch of lnor spaces ;)
>>>>
>>>> Le 09/06/2017 à 19:01, Rohan Rathi a écrit :
>>>>
>>>> One thing, I'd like to ask, be it whole or selective invalidation. But
>>>> should I implement an invalidate mechanism for transform ops?
>>>>
>>>> On Fri, Jun 9, 2017 at 10:27 PM, Rohan Rathi <rohanrathi08 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> I understand the complexity of selective invalidation. While debugging
>>>>> the code, I realised that whenever a vertex is say moved, all the loops of
>>>>> all the faces that share the vertex have their lnor spaces modified which
>>>>> is why the function BM_lnorspace_invalidate marks the all loops for each
>>>>> face sharing the vertex for rebuilding.
>>>>>
>>>>> As you suggest, there are more cases to consider(all loops become part
>>>>> of a smooth fan) or even call it splitting/ merging clnors. I'll work on my
>>>>> proposed features for now. But as I find time I'll most likely take up to
>>>>> tackling these issues with your help. Although I feel the implementation
>>>>> could have been better.
>>>>>
>>>>> Thank you,
>>>>> Rohan
>>>>>
>>>>> On Fri, Jun 9, 2017 at 6:56 PM, Bastien Montagne <
>>>>> montagne29 at wanadoo.fr> wrote:
>>>>>
>>>>>> Hey Rohan,
>>>>>>
>>>>>> Did not have time to check commits in detail unfortunately, but from
>>>>>> quick review I think you should keep the 'invalidate only some lnor spaces'
>>>>>> idea out of code for now. In other words, just always invalidate whole
>>>>>> array of lnor spaces (you can keep the two defines for now, just make the
>>>>>> 'partial' one behave like the 'everything' one e.g.).
>>>>>>
>>>>>> Reason is, it's not easy to determine which lnor space needs to be
>>>>>> recomputed based on which vert/edge/face was edited (e.g. moving a single
>>>>>> vertex can invalidate all lnor spaces around that vertex, but also those
>>>>>> involving neighbor vertices of adjacent faces…). Better to keep that kind
>>>>>> of refinement for later, if time allows (and rebuilding all lnorspaces
>>>>>> shows to be a real bottleneck, which I kind of doubt). Even worse, it can
>>>>>> create or delete some lnorspaces (due e.g. the face angle going above/below
>>>>>> 'sharp' threshold, etc.).
>>>>>>
>>>>>> Keep up the good work! :)
>>>>>> Bastien
>>>>>> Le 02/06/2017 à 19:39, Rohan Rathi a écrit :
>>>>>>
>>>>>> What I did this week:
>>>>>>
>>>>>> Fairly rudimentary work. Cached the custom loop normal spaces for the
>>>>>> mesh and added a mechanic to detect when the loop normal spaces are dirty
>>>>>> and rebuild the loop normal space array.
>>>>>>
>>>>>> Other than that I developed a much stronger understanding of BMesh
>>>>>> Ops. All bmesh ops that are executed should now either flag the loops of
>>>>>> the modified geometry or invalidate the entire loop normal space array of
>>>>>> the mesh.
>>>>>>
>>>>>> What I plan on doing next week:
>>>>>>
>>>>>> Now that this is cleared, I think I can focus on writing the actual
>>>>>> tools that will manipulate the custom normal. My first goal was to add the
>>>>>> ability to rotate normals. I've studied modal rotation already and most
>>>>>> likely will have added this ability by the end of next week.
>>>>>>
>>>>>> Although all BMesh Ops that modify geometry are taken care of, there
>>>>>> are other tools that manipulate geometry like modal transform. So I need to
>>>>>> figure out a way to invalidate the loop normal spaces in this case. This
>>>>>> will be my prior task along with normal rotation.
>>>>>>
>>>>>>
>>>>>> Links:
>>>>>> My proposal: https://wiki.blender.org/index.php/User:RohanRathi
>>>>>> /GSoC_2017/Proposal
>>>>>> Git branch: https://developer.blender.org/diffusion/B/browse/soc
>>>>>> -2017-normal-tools/
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Rohan Rathi
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Soc-2017-dev mailing listSoc-2017-dev at blender.orghttps://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>
>>>>>> _______________________________________________ Soc-2017-dev mailing
>>>>>> list Soc-2017-dev at blender.org https://lists.blender.org/mail
>>>>>> man/listinfo/soc-2017-dev
>>>>>
>>>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170717/07ce761c/attachment-0001.htm 