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

Progress Report (11/9 - 11/15)

This week: I struggled to update the Grapher files at the website www.ccd.rpi.edu/eglash/csdt/pcsdt/GG/. Today I met with Eddie and he helped me update the files.

Next week: I will show off my updated Grapher and see what is liked/disliked. I will go from there and change accordingly. After that I plan to find what else to add/change/remove.

Progress Report (11/2 - 11/8)

This week: I removed the codelets move by, move arc, write text, and increase line width by. I also renamed the codelets Move By 3D and Move Arc 3D to Move Straight and Move Arc. I made two new codelets, set heading and change heading. These codelets take a number and modify the direction to move in. Set is absolute and change is relative to the current heading. Although I have added more codelets, the overall feel is much less intimidating than before. This is mainly due to the decrease in the number of total arguments within all codelets. Lastly, I updated the demo script to work with the new set of functions.

Next week: Rework the codelet to draw arcs. I fear that the current way may be better if changed to not use iteration rather than the angle sweeping idea proposed. I will discuss this in the next meeting.

Progress Report (10/27 - 11/1)

This week: I fixed the function MoveBy. As of right now it is only locally fixed and I cannot commit.

Before: This would just fail and crash the program on a MoveBy function.

After: This now performs the MoveBy correctly and continues

I also thought of an idea to change the 3d functions (MoveBy3d, DrawArc3d,etc) to have the width change parameter to all be like the MoveBy3d, make these so they are total width change instead of each iteration. As of right now some are total and some are with each iteration, by making them all total this would lead to everything being similar and would make the program feel less like iteration which is what I believe Profressor Eglash wants.

Next Week: I plan to ask about my 3d functions idea and find out how to commit. I believe all I need is to be put into the list of those who are allowed to commit. I have a file Eddie gave me, but it appears to be from July, so I also plan to ask about what else to do and make sure they still want to implement the ideas that haven't already been implemented.

Progress Report (10/19 - 10/26)

What I have done this week: As of this week I can now compile and run the project to use the applet. I have read over some of the Core code as well as some of the Grapher code.

Next week: Attempt to read and understand the rest, or at least enough to start working in confidence. Also I plan to read up on Jogl. Having worked with Java so little lately I am relearning to an extent.

Progress Report (10/12 - 10/18)

What I accomplished the past week:
I set up my blog for my weekly progress in the project. I have installed the NetBeans IDE on my laptop and desktop. I set up the subversion within NetBeans by using Professor Eglash's information to log in  temporarily. I believe I checked out all the files without checking them back in, and am unsure how to fix this. Sorry to all those affected.

What I plan to do:
Gain more understanding of the Subversion as well as the code. Figure out what must be done to relate the core. I remember seeing something related to this in Professor Eglash's office during the first meeting I attended. Also, Figure out how or what must be done to link this blog to the CSDT Developers' Blogs portion of the wiki site.