This week in gist:<br>1. Began by researching how operators are set up by tackling a couple bug reports.<br>2. Ended with very little work being done as a result of sickness.<br><br>Below follows specifics copied from notes recorded here: <a href="http://wiki.blender.org/index.php/User:PrototypeNM1/Weekly_Report#Week_5">http://wiki.blender.org/index.php/User:PrototypeNM1/Weekly_Report#Week_5</a><br>
<h2><span class="mw-headline" id="Week_5"></span></h2><h2><span class="mw-headline" id="Week_5">Week 5</span></h2>
<h3><span class="editsection"></span><span class="mw-headline" id="Sunday">Sunday</span></h3>
<p>I cleaned up some compile errors in MSVS in order to confirm that MinGW and MSVC now function the same.
</p>
<h3><span class="editsection"></span><span class="mw-headline" id="Monday_2">Monday</span></h3>
<p>I'm still getting to grips with the Window Manager. While studying
the code I noticed a bit that could benefit from a simple change of
name, specifically change "custom" to "customdatatype" in
wm_event_system. I still need to find the best point to register touch
as a modal event. I believe I read through most of the code relating to
it in the window manager today so I believe I have a good base for
tomorrow.
</p><p>I also noticed a graphical bug during drag and drop, the
subwindow(?) borders do not update until any border is moved. I'd guess
it's a simple notifier missing, which I might look into later. I also
confirmed today a weird glitch where disabling "WITH_RAYOPTIMIZATION" in
both swiss_cheese and trunk for MinGW causes most text to disappear. I
don't believe this was the case when the summer began, though it might
be an issue with my system.
</p>
<h3><span class="editsection"></span><span class="mw-headline" id="Wednesday_3">Wednesday</span></h3>
<p>I decided to spend some time bugfixing for the past couple days in
order to get a better feel of how operators work and contribute
something in the process. In the process I committed fixes for "[#31577]
Select N-th vertex/face/edge doesnt work" and "[#31433] BMesh: Knife
tool Angle Constraint function". The latter took a bit longer than
expected, it's now 5 in the morning here which is why this update is
brief.
</p>
<h3><span class="editsection"></span><span class="mw-headline" id="Friday_3">Friday</span></h3>
<p>Expanding on the last update, the two bugfixes I worked on were:
</p>
<ul><li> <a href="http://projects.blender.org/tracker/index.php?func=detail&aid=31577&group_id=9&atid=498" class="external text" rel="nofollow">#31577 Select N-th vertex/face/edge doesnt work</a>
</li><li> <a href="http://projects.blender.org/tracker/?func=detail&atid=498&aid=31433&group_id=9" class="external text" rel="nofollow">#31433 BMesh: Knife tool Angle Constraint function</a>
</li></ul>
<p>The reasoning I set forth working on bugfixes was two parts. First,
the tracker had come up in the past two weekly meetings, so I figured I
have a go at a couple of the issues. Second, it was a great opportunity
to see how other operators function in Blender.
</p><p>The former bug was actually documented in the code once I got to
look into it. In short, the issue was that loop selections did not
update the clicked face as active. This caused errors with N-th face
selection which is reliant on checking the active face and associated
loops. The fix was pretty simple, call the existing function that sets a
face as active based on mouse position. This led to cleaner code and
fixing all issues commented in that section.
</p><p>The latter bug, while very educational for my project regarding
handling modal events, led me to realizing that the knife code is a bit
messy for the time being (the fact that it's messy is even documented in
the code XD ). The issue I found in the code was that mouse position
was stored, but not updated when vertex or edge snapping occurs (not
necessary for face snapping of course). This caused issues when
constraining to angles, which is reliant on previously recorded mouse
positions. The fix for vertex snapping was pretty straight forward, as
knife vertices calculate and store their relative screen position when
created, a fact I used to then correct edge snapping.
</p><p>While the core problem of the report was fixed, there are still
several shortcomings of the existing system, such as ignoring angle
constraints when vertex/edge snapping occurs. An eventual rewrite of
this might also take advantage of existing snap code instead of custom
knife snap code. An additional shortcoming (thought admittedly a mild
one) is that overlapping edges (like those which occur when viewing an
orthographic box from any side) might register the overlapping edges as a
cutting line, going from front to back, causing the intended cut across
a visible face to be rejected for cutting. A simple screen space check
in the the edge hit code might fix this.
</p><p>For the past two days (Thursday and Friday) I have been dealing
with a drive by cold. Thursday I fixed an error I introduced and later
noticed while trying to fix the second bug; today was not very
productive at all. :(
</p>
<h3><span class="editsection"></span><span class="mw-headline" id="Next_Week_4">Next Week</span></h3>
<p>Bug hunting in the knife operator was very beneficial, in that I read
through quite a bit of code which gives me an idea as to how I might
set up my operators. I'll need to return to plans for next week when my
mind is a bit more clear though.
</p><br>