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

Thu Jul 20 20:22:08 CEST 2017

Hey :)

After researching about weighted normals I've coded a base for the
modifier, would appreciate some feedback.
As far as the implementation goes, the different weighting modes are
standard (face area/ corner angle/ face area corner angle). I've added a
weight integer in the modifier which exponentially divides values (area/
angle) in different modes and a threshold value to consider the limit in
the values which will be weighted equally. Here value represents the
weighting mode value so it can be face area or corner angle.

I've coded this method for face area and can push an early commit so that
you can test it and provide better advice.
I've added 2 pictures of the modifier with a bevel modifier on the cube to
show how it performs.

Also, there are some silhouettes with the modifier, I guess that is to
expected?

On Tue, Jul 18, 2017 at 2:16 PM, Bastien Montagne <montagne29 at wanadoo.fr>
wrote:

> I think an 'active' color for edited normals would make sense yes.
>
> Le 17/07/2017 à 18:50, Rohan Rathi a écrit :
>
> 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/20170720/6abd4ba0/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weight_2.png
Type: image/png
Size: 64520 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170720/6abd4ba0/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weight_15.png
Type: image/png
Size: 66679 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170720/6abd4ba0/attachment-0003.png 