<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="h5">
<br>
<div class="m_-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_-7119076344769285543h5">
<div class="m_-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_-7119076344769285543m_-7719612261318483939h5">
<div class="m_-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_-7119076344769285543m_-7719612261318483939m_8215168633730240945h5">
<br>
<div class="m_-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_-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_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024h5">
<div class="m_-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_-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_-7119076344769285543m_-7719612261318483939m_8215168633730240945m_-3303108875460607863m_460743453314125316m_6808958345619108024m_-9165392130011764435mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
Soc-2017-dev mailing list
<a class="m_-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_-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>