[Soc-2012-dev] Multitouch Weekly Report

[Luke Frisken]

Hi Nick,
I had to have a little laugh, many of the exact same thoughts you had in
your Friday entry were going through my head when I was writing my
proposal. At the time I was looking to improve the angle snapping on the
knife tool by including axis snapping (rather than being in screen space
for angle snapping) after a discussion I had with Howard. It's part of my
motivations for making the new snapping system more generic (less transform
oriented) so it would be possible for the knife tool to begin using it down
the track.

On Sat, Jun 23, 2012 at 3:31 PM, Nick Rishel <nrishel at iupui.edu> wrote:

> 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.
>
>
> _______________________________________________
> Soc-2012-dev mailing list
> Soc-2012-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2012-dev
>
>


-- 
>From Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2012-dev/attachments/20120624/de52b42d/attachment.htm