[Soc-2017-dev] Weekly Report #01 - Normal Editing Tools
Bastien Montagne
montagne29 at wanadoo.fr
Tue Jul 18 10:46:27 CEST 2017
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>>>> <mailto: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
>>>>> <mailto: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
>>>>>> <https://wiki.blender.org/index.php/User:RohanRathi/GSoC_2017/Proposal>
>>>>>> Git branch:
>>>>>> https://developer.blender.org/diffusion/B/browse/soc-2017-normal-tools/
>>>>>> <https://developer.blender.org/diffusion/B/browse/soc-2017-normal-tools/>
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Rohan Rathi
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Soc-2017-dev mailing list
>>>>>> Soc-2017-dev at blender.org
>>>>>> <mailto:Soc-2017-dev at blender.org>
>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>> <https://lists.blender.org/mailman/listinfo/soc-2017-dev>
>>>>> _______________________________________________
>>>>> Soc-2017-dev mailing list
>>>>> Soc-2017-dev at blender.org
>>>>> <mailto:Soc-2017-dev at blender.org>
>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>> <https://lists.blender.org/mailman/listinfo/soc-2017-dev>
>>>>>
>>>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170718/49775773/attachment-0001.htm
More information about the Soc-2017-dev
mailing list