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.
Wednesday, February 22, 2012
Thursday, February 16, 2012
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
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
Wednesday, February 8, 2012
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.
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.
Tuesday, December 13, 2011
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 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
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
Tuesday, November 15, 2011
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.
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.
Tuesday, November 8, 2011
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.
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.
Tuesday, November 1, 2011
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.
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.
 |
| 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.
Subscribe to:
Posts (Atom)