<div dir="ltr">Hey :)<div><br><div>After researching about weighted normals I've coded a base for the modifier, would appreciate some feedback.</div></div><div>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.</div><div><br></div><div>I've coded this method for face area and can push an early commit so that you can test it and provide better advice.</div><div>I've added 2 pictures of the modifier with a bevel modifier on the cube to show how it performs.</div><div><br></div><div>Also, there are some silhouettes with the modifier, I guess that is to expected?</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 18, 2017 at 2:16 PM, Bastien Montagne <span dir="ltr"><<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>I think an 'active' color for edited normals would make sense
yes.<br>
</p><div><div class="h5">
<br>
<div class="m_7222829400978294585moz-cite-prefix">Le 17/07/2017 à 18:50, Rohan Rathi a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Sure :)
<div>Adding a new layer to faces does seem nice.. I'll discuss
with Campbell.</div>
<div>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?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jul 17, 2017 at 9:31 PM,
Bastien Montagne <span dir="ltr"><<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hey Rohan,</p>
<p>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!</p>
<p>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).</p>
<p>Sending to the list, please keep the discussion on it
now ;)</p>
<p>Cheers,<br>
Bastien<br>
</p>
<div>
<div class="m_7222829400978294585h5"> <br>
<div class="m_7222829400978294585m_-7119076344769285543moz-cite-prefix">Le
17/07/2017 à 17:54, Rohan Rathi a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey,
<div>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.</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Thank you</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jul 3, 2017 at
2:09 PM, Bastien Montagne <span dir="ltr"><<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hi Rohan,</p>
<span>
<p>> 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.</p>
</span>
<p>Yep, agree, generic poll function would
be nice here.<br>
</p>
<div>
<div class="m_7222829400978294585m_-7119076344769285543h5">
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939moz-cite-prefix">Le
30/06/2017 à 21:11, Rohan Rathi a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
<div>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.</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jun
27, 2017 at 7:30 PM, Bastien
Montagne <span dir="ltr"><<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hi Rohan,</p>
<p>And sorry for delay in
answers… :/</p>
<p>Not sure where you are now
re merging clnors?</p>
<p>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.</p>
<p>Which only leaves us with
sharp edges. So process
could merely be:<br>
* (optional) compute new
value of merged normals.<br>
* check edges between merged
normals, and remove sharp
ones.<br>
* recompute lnor spaces.<br>
* (optional) set previously
new value for merged
normals.</p>
<p>Same goes for spliting
normals btw, just add sharp
edges in-between split
clnors, and you are done.</p>
<p>------------<br>
</p>
<p>Now, have checked quickly
your branch today, looks
good generally (did very
quick skimming over the
code, obviously not in-depth
detailed review ;) ).</p>
<p>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?</p>
<p>------------</p>
<p>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.
:)</p>
<p>Keep up the good work,<br>
Cheers,<br>
Bastien<br>
</p>
<div>
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939h5">
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945moz-cite-prefix">Le
24/06/2017 à 16:58,
Rohan Rathi a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey,
<div>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.</div>
<div><br>
</div>
<div>Also, I dont
exactly know how to
tackle merging loop
normals. </div>
<div>Any guidance
appreciated! :)</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Mon, Jun 12, 2017 at
12:24 PM, Bastien
Montagne <span dir="ltr"><<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Yes,
definitively
think
invalidation
is also needed
for transform
ops, just
moving a
single vertex
can invalidate
a bunch of
lnor spaces ;)<br>
</p>
<div>
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945h5">
<br>
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863moz-cite-prefix">Le
09/06/2017 à
19:01, Rohan
Rathi a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">One
thing, I'd
like to ask,
be it whole or
selective
invalidation.
But should I
implement an
invalidate
mechanism for
transform ops?</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Fri, Jun 9,
2017 at 10:27
PM, Rohan
Rathi <span dir="ltr"><<a href="mailto:rohanrathi08@gmail.com" target="_blank">rohanrathi08@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi,
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thank
you,</div>
<div>Rohan</div>
<div>
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Fri, Jun 9,
2017 at 6:56
PM, Bastien
Montagne <span dir="ltr"><<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hey Rohan,</p>
<p>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.).</p>
<p>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.).<br>
</p>
<p>Keep up the
good work! :)<br>
Bastien<br>
</p>
<div>
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024h5">
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024m_-9165392130011764435moz-cite-prefix">Le
02/06/2017 à
19:39, Rohan
Rathi a
écrit :<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024h5">
<div dir="ltr">What
I did this
week:
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>What I
plan on doing
next week:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div>Links:</div>
<div>My
proposal: <a href="https://wiki.blender.org/index.php/User:RohanRathi/GSoC_2017/Proposal" target="_blank">https://wiki.blender<wbr>.org/index.php/User:RohanRathi<wbr>/GSoC_2017/Proposal</a></div>
<div>Git
branch: <a href="https://developer.blender.org/diffusion/B/browse/soc-2017-normal-tools/" target="_blank">https://developer.blen<wbr>der.org/diffusion/B/browse/soc<wbr>-2017-normal-tools/</a></div>
<div><br>
</div>
<div><br>
</div>
<div>Thank
you,</div>
<div><br>
</div>
<div>Rohan
Rathi</div>
</div>
<br>
<fieldset class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024m_-9165392130011764435mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
Soc-2017-dev mailing list
<a class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024m_-9165392130011764435moz-txt-link-abbreviated" href="mailto:Soc-2017-dev@blender.org" target="_blank">Soc-2017-dev@blender.org</a>
<a class="m_7222829400978294585m_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024m_-9165392130011764435moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/soc-2017-dev" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/soc-2017-dev</a>
</pre>
</blockquote>
</div>
______________________________<wbr>_________________ Soc-2017-dev
mailing list <a href="mailto:Soc-2017-dev@blender.org" target="_blank">Soc-2017-dev@blender.org</a>
<a href="https://lists.blender.org/mailman/listinfo/soc-2017-dev" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/soc-2017-dev</a>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>