Progress Report (3/28 - 4/3)

This week: I was tasked with the bumps of shapes caused by some parameters. I met with Jed and he explained a possible solution to the problem. He ended up implementing the solution himself. I find this solution does look nicer, but it still has some strange areas where the shape looks odd. Same as last week the shapes look odd beyond 90 degrees with a width change, but this is due to the design. At first I didn't like the look of the new shapes based off the new control point formula but they grew on me. I see more of a graffiti look in them. I wanted to modify the control point formula further but could not come up with anything. The bumps are indeed gone.

 The Old: The bump is visible at the top.   

The New: The control points are shifted.

Next week: See what the others think, likely further edit the control point further. I need to discuss the 90++ angles with the others as well. I also have a basic idea for logarithmic spirals but I am not certain if those will be involved yet. I do however believe they will be much more complex than the basic idea will work for.

Progress Report (3/21 - 3/27)

This week: I was able to fix the incorrect way the shape function was drawing. I also added functionality to above 90 degrees and below -90 degrees (this was a previous limitation). I find the current way shapes draw beyond the +/- 90 degrees to be slightly awkward looking.

Next week: Get feedback on what I currently have and work accordingly

Progress Report (2/29 - 3/6)

This week: I was rather busy with other work. First, I added a second demo, this demo is merely a start with a SprayCan setup already and two codelets. Second, I slightly editted the GGGui.html, this was mainly a sidetrack, but if I did what I intended properly GG should still work. I can however revert easily if needed. Third, I continued progress on Shapes, I removed the error that was there, then there error that the fix caused.

The filled shape with no angle            The filled shape at a 50° angle

Though the shape on the right looks close to correct, it is not. The control point locations error become much more obvious at low or higher degree angles.

With all other parameters the same and an angle of 5°, the error becomes quite obvious.

Next Week: I would like to tackle my logical error involved with the control points. This is the last foreseen problem for the shapes other than the angle limits, which should be much easier to fix.

Progress Report (2/16 - 2/22)

This week: I removed the error from last week. I started the shapes I was asked to do. I have the lines set up, but the arcs between are not set up as of yet. This should not be too hard to set up, I merely didn't get around to it. For the time being the size is exaggerated to make it more visible.

Next week: Finish shape and possibly move on to reducing the complexity of the scripts.

Progress Report (2/9 - 2/15)

Sorry for the late post. This is what I would have posted a couple days ago.

This week: I attempted a simple way of using super sampling to alleviate the jaggedness of the current arcs. This however didn't work. If I were to pursue this further it would require more work to be done but should be doable. I however would not likely be pursuing this. The main progress of this week was in my meeting with Jed. We met and he helped me to reach a possible solution. I did not have time to implement this solution, but plan to do so soon. Lastly, I commited the files on my desktop which worked but when I pulled them on my laptop running the project results in an error.

Next Week: I plan to fix the error and start implementing what Jed has informed me about

Progress Report (1/26 - 2/8)

This post is for two week because I forgot to post the previous week. Both weeks were rather frustrating and disappointing. 1/26-2/1 being in regard to the end of attempting to use Java2D arcs and attempting to find another solution to draw arcs that can use built-in antialiasing while being able to change the width of the arc. Professor Eglash suggested Bezier curves, and these would likely work. The width part I would find out once I got there, assumingly a teardrop shape with a filled inside (if possible). I plan to use QuadCurve2D arcs. Sadly I struggle with the math that is required to set up bezier curves. This week (2/2-2/8) in specific I have basically been learning about bezier curves, but I have made little progress in regards to the project once again. Overall I feel I just need to give more time on this project.

Next week: I plan to spend more time next week on the project and ask questions whenever I feel stuck from here on out. I hope to find some sort of help for this part relating to QuadCurve2D arcs because I am stuck.

Progress Report (12/7 - 12/13)

First off I apologize for not really posting at all on my blog in the past few weeks. Moving on.

This week: I have attempted to work with Java2D to make the arcs rather than through the use of multiple calls to moveby3d and changing the heading during the loop. After much thought of how to get the arcs drawn by Java2D to work how they are intended to work and a few tries, I have decided that it would be best to not use Java2D's arcs. This is because of two properties of Java2D arcs: 1. The way I would be using them would not be the way they were designed, This would mean hacking their properties to get them to work the way I want them to; 2. The ability to change the width along the way of the arc would not be possible by merely redrawing the arcs based off the way they are drawn. To explain further, an arc constructor takes 6 floats and an int for type. These floats are 4 for the box, an X and Y for one corner and a width and height of the box, as well as starting angle and angle extent. For 1, the way the Java2D arcs are designed the arguments define a box that is the space that contains the arc. The arc is contained within this space and is drawn around the center of the box, this is not what we are looking for since we have is a starting point; with the starting point not every being able to be entirely within the box, we have to move the box. This would seem hackish but theoretically not that difficult. For 2, the ability to change the width of the arc seems to me much more hard and hacked than reason 1, this is because I see no way to change the width of the arcs as they are draw other than to repeatably use them and that would be a complete waste because the whole reason was to use Java2D arcs instead of repeatably using dots/lines of move by. Unless I am informed otherwise I believe that Java2D's arcs would not be the best form to use this. In that respect I updated the code on my computer to use more calls of move by to be sharper. Sadly this is not a form of anti-aliasing that Professor Eglash asked for, it merely looks better than the previous form.

The first form, which while it looks good, some of the lines are choppy on the smaller arcs of the letters.

The second form does indeed look better. I personally didn't realize it at first because I was mainly
focusing on the larger red arcs.

The last thing I did was to update the heading to be counter clockwise and not clockwise. This change was made to work with standard of counter-clockwise angles in mathematics.

Next: I plan to discuss what the other think of the arcs, I feel silly taking so long to make progress on this, but I have been busy with other class work and I was quite honestly a bit stubborn on the idea that I should make this work. After finally clearing my mind of other classes for a bit I realized the difficulty of getting Java2D arcs to work as we want them to work in this program