[Soc-2012-dev] Multitouch Weekly Report

[Nick Rishel]

Luke,

That's excellent, I was thinking of your project as I was writing my
report! I could not recall what the scope of your project was though. :)

Nick

On Sat, Jun 23, 2012 at 10:29 PM, Luke Frisken <l.frisken at gmail.com> wrote:

> 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
>
> _______________________________________________
> Soc-2012-dev mailing list
> Soc-2012-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2012-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2012-dev/attachments/20120625/f86a38a6/attachment.htm