[Soc-2012-dev] Multitouch Weekly Report

Nick Rishel nrishel at iupui.edu
Sat Jun 23 07:31:44 CEST 2012


This week in gist:
1. Began by researching how operators are set up by tackling a couple bug
reports.
2. Ended with very little work being done as a result of sickness.

Below follows specifics copied from notes recorded here:
http://wiki.blender.org/index.php/User:PrototypeNM1/Weekly_Report#Week_5
Week 5 Sunday

I cleaned up some compile errors in MSVS in order to confirm that MinGW and
MSVC now function the same.
Monday

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.

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.
Wednesday

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.
Friday

Expanding on the last update, the two bugfixes I worked on were:

   - #31577 Select N-th vertex/face/edge doesnt
work<http://projects.blender.org/tracker/index.php?func=detail&aid=31577&group_id=9&atid=498>
   - #31433 BMesh: Knife tool Angle Constraint
function<http://projects.blender.org/tracker/?func=detail&atid=498&aid=31433&group_id=9>

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.

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.

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.

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.

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. :(
Next Week

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2012-dev/attachments/20120623/68215232/attachment.htm 


More information about the Soc-2012-dev mailing list