Due: Tuesday, April 25, 2017, 11:59 pm

Non-Photorealistic Rendering

For the project, you'll need to implement two more styles of drawing. To implement a new style, you just need to add another case to the if statement in the forward method of the TurtleInterpreter class.

The last step in the project is to enhance your scene from the last project by making use of the various styles you implement this week. You should be able to run the scene with different styles with minimal changes to your code.

Tasks

1. Implement a style 'jitter3' that draws the line segment as three, criss-crossing jittered lines. The implementation is similar to the 'jitter' case, but instead of drawing one line, you draw three. All three lines should begin at a point that is a short, random distance from the turtle's initial position and end at at a point that is a short, random distance from the desired end point.

   This will involve several goto statements, e.g.

     jx = random.gauss(0,self.jitterSigma)
     jy = random.gauss(0,self.jitterSigma)
     turtle.goto( x0+jx, y0+jy )
   

   For each goto statement, the jx and jy values should be regenerated from a Gaussian distribution (random.gauss) with a zero mean and jitterSigma as the standard deviation. They should not all be the same.

2. Create a 'dotted' style that draws a series of circles separated by spaces. Create a field in the TurtleInterpreter to hold the dotSize (the radius of the circle). You'll also need a setDotSize method in the TurtleInterpreter class and a setDotSize method and associated dotSize field in the Shape class, just as we did with the setStyle and setJitter information.
3. Make a file demo_line_styles.py that draws multiple copies of one of your shapes from last week. Show the shape drawn in 'normal', 'jitter', and 'jitter3', and 'dotted' styles. For the normal style, draw shapes with at least 2 different line widths. For jitter and jitter3 styles, draw shapes with at least 2 different jitter sigmas. For the dotted style, draw shapes with at least 2 different dot sizes.

   An image demonstrating your different styles is required image 1.

4. Make a copy of your indoor scene code from last week--or create a brand new scene-- and put it in a new file indoor_scene.py. Edit your scene so that it makes use of the different drawing styles. Feel free to enhance it, but focus on enhancements that make use of the different drawing styles and shape classes you've created. When you are done, you should have something that looks a bit more like a real painting or drawing.

   The updated indoor scene is required image 2.

5. Make your own new parameterized stochastic multi-rule L-system. You can create a variation on one of the given files or look in ABOP for inspiration. If you create a variation, you need to do more than just add ornaments (berries or leaves). You need to make the shape structurally different so the difference is obvious.

   Your new L-system does not have to be a tree, but it does need to include branching, multiple rules, and at least one rule with more than one replacement string. Describe the L-system you designed in your writeup and explain your design choices. Make a scene or image that includes your L-system. If you have altered an L-system from ABOP or elsewhere, please show your L-system next to that L-system so you can make it clear there are differences. Please also supply the name of the file that contains the rules for the L-system so that we can find it when we are grading.

   A picture of the new L-system is required image 3.

Extensions

• Create more L-systems. Show how they differ in their design.
• Add other drawing styles that you created. For example, try making one that simulates a brush by drawing many approximately parallel lines. Slight variations in color between the different lines makes the effect better. You might also try a pen-and-ink style with cross-hatching or just a series of straight lines at an angle to the direction of the actual line.
• Modify drawString so that when drawing a tree the branches droop down like gravity is pulling at them. This involves determining the turtle's current angle. If the current heading is in the first or fourth quadrant, then gravity will make a right turn angle larger. If the current heading is in second or third quadrant, then gravity will make a right turn angle smaller.
• Create a sequence of images to build an animation.
• Make more shape classes that do interesting things. Making a fixed sequence of characters is easy. Make a shape class where the strings are the result of executing a function. L-systems are one example of a dynamically created string, but there are many other ways to do that.
• Be more creative with your main code. In other words, use programming structures, user input, and code to go beyond the minimal required image.

Write-up and Hand-in

Turn in your code by putting it into your private hand-in directory on the Courses server. All files should be organized in a folder titled "Project 10" and you should include only those files necessary to run the program. We will grade all files turned in, so please do not turn in old, non-working, versions of files.

Make a new wiki page for your assignment. Put the label cs151s17project10 in the label field on the bottom of the page. But give the page a meaningful title (e.g. Ying's Project 10).

In general, your intended audience for your write-up is your peers not in the class. Your goal should be to be able to use it to explain to friends what you accomplished in this project and to give them a sense of how you did it. Follow the outline below.

• A brief summary of the task, in your own words. This should be no more than a few sentences. Give the reader context and identify the key purpose of the assignment.
• A description of your solution to the tasks, including any images you created. This should be a description of the form and functionality of your final code. You may want to incorporate code snippets in your description to point out relevant features. Note any unique computational solutions you developed. Code snippets should be small segments of code--usually less than a whole function--that demonstrate a particular concept. If you find yourself including more than 5-10 lines of code, it's probably not a snippet. You should not include all your code in the writeup
• A description of any extensions you undertook, including images demonstrating those extensions. If you added any modules, functions, or other design components, note their structure and the algorithms you used.
• A brief description (1-3 sentences) of what you learned.
• A list of people you worked with, including TAs, and professors. Include in that list anyone whose code you may have seen, such as those of friends who have taken the course in a previous semester.
• Don't forget to label your writeup so that it is easy for others to find. For this lab, use cs151s17project10

To check whether you've made your code snippets and the associated text clear, you may ask yourself the following questions:

• Does the text describe the context of the code snippet within the code?
• Does the text describe the purpose of the code snippet (i.e. what your goal was when you wrote the code)?
• Does the text describe the overall strategy taken by the code snippet? (e.g. loop over the list so that each element could be capitalized)
• Does the code snippet itself make the write-up clearer than it would be without the code snippet? (Does the specific example help?)
• Is the code snippet as short as possible? (It should be possible to make your point with 5-10 lines of code).

© 2017 Ying Li. Page last modified: .