[Soc-2017-dev] Weekly Report #01 - Normal Editing Tools
Bastien Montagne
montagne29 at wanadoo.fr
Fri Jul 21 12:13:55 CEST 2017
Hey Rohan,
Looks promising, not sure about those silhouettes, but iirc you tend to
get similar effects with existing 'set normals' modifier too - think
it's related to having normals too far away from “natural” vertices
ones, or something similar…
Le 20/07/2017 à 20:22, Rohan Rathi a écrit :
> 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 <mailto: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 <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/20170721/82eb75db/attachment-0001.htm
More information about the Soc-2017-dev
mailing list