[Soc-2017-dev] Weekly Report #01 - Normal Editing Tools
Bastien Montagne
montagne29 at wanadoo.fr
Mon Jul 17 18:01:32 CEST 2017
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/20170717/474001c1/attachment-0001.htm
More information about the Soc-2017-dev
mailing list