<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hey Rohan,</p>
<p>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…<br>
</p>
<br>
<div class="moz-cite-prefix">Le 20/07/2017 à 20:22, Rohan Rathi a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAE7L-20YiaAjZqWxdZ1eHZqnYBA5s8EbTv-vkQaPWU=Ycrxv+A@mail.gmail.com">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">Soc-2017-dev@blender.org</a>
<a
href="https://lists.blender.org/mailman/listinfo/soc-2017-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">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>
</blockquote>
<br>
</body>
</html>