Updated README

README.md

@@ -3,7 +3,7 @@ CIS565: Project 1: CUDA Raytracer
 -------------------------------------------------------------------------------
 Fall 2012
 -------------------------------------------------------------------------------
-Due Tuesday, 09/25/2012
+Due Sunday, 09/30/2012
 -------------------------------------------------------------------------------
 
 -------------------------------------------------------------------------------
@@ -77,7 +77,7 @@ You will be working in three files: raytraceKernel.cu, intersections.h, and inte
 
 * intersections.h contains functions for geometry intersection testing and point generation. You will need to complete:
 	* boxIntersectionTest(), which takes in a box and a ray and performs an intersection test. This function should work in the same way as sphereIntersectionTest().
-	* getRandomPointOnSphere(), which takes in a sphere and returns a random point on the surface of the sphere with an even probability distribution. This function should work in the same way as getRandomPointOnCube().
+	* getRandomPointOnSphere(), which takes in a sphere and returns a random point on the surface of the sphere with an even probability distribution. This function should work in the same way as getRandomPointOnCube(). You can (although do not necessarily have to) use this to generate points on a sphere to use a point lights, or can use this for area lighting.
 
 * interactions.h contains functions for ray-object interactions that define how rays behave upon hitting materials and objects. You will need to complete:
 	* getRandomDirectionInSphere(), which generates a random direction in a sphere with a uniform probability. This function works in a fashion similar to that of calculateRandomDirectionInHemisphere(), which generates a random cosine-weighted direction in a hemisphere.
@@ -139,10 +139,36 @@ Objects are defined in the following fashion:
 An example TAKUAscene file setting up two frames inside of a Cornell Box can be found in the scenes/ directory.
 
 -------------------------------------------------------------------------------
-SUBMISSION
+BLOG
+-------------------------------------------------------------------------------
+As mentioned in class, all students should have student blogs detailing progress on projects. If you already have a blog, you can use it; otherwise, please create a blog using www.blogger.com or any other tool, such as www.wordpress.org. Blog posts on your project are due on the SAME DAY as the project, and should include:
+
+* A brief description of the project and the specific features you implemented.
+* A link to your github repo if the code is open source.
+* At least one screenshot of your project running.
+* A 30 second or longer video of your project running.  To create the video use http://www.microsoft.com/expression/products/Encoder4_Overview.aspx 
+
+-------------------------------------------------------------------------------
+THIRD PARTY CODE POLICY
 -------------------------------------------------------------------------------
-As with the previous project, you should fork this project and work inside of your fork. Upon completion, commit your finished project back to your fork. DO NOT make a pull request to merge back to the master version.
-You should include a README file detailing what features you implemented, any difficulties you had, and so on and so forth.
+* Use of any third-party code must be approved by asking on Piazza.  If it is approved, all students are welcome to use it.  Generally, we approve use of third-party code that is not a core part of the project.  For example, for the ray tracer, we would approve using a third-party library for loading models, but would not approve copying and pasting a CUDA function for doing refraction.
+* Third-party code must be credited in README.md.
+* Using third-party code without its approval, including using another student's code, is an academic integrity violation, and will result in you receiving an F for the semester.
 
+-------------------------------------------------------------------------------
+SELF-GRADING
+-------------------------------------------------------------------------------
+* On the submission date, email your grade, on a scale of 0 to 100, to Karl, yiningli@seas.upenn.edu, with a one paragraph explanation.  Be concise and realistic.  Recall that we reserve 30 points as a sanity check to adjust your grade.  Your actual grade will be (0.7 * your grade) + (0.3 * our grade).  We hope to only use this in extreme cases when your grade does not realistically reflect your work - it is either too high or too low.  In most cases, we plan to give you the exact grade you suggest.
+* Projects are not weighted evenly, e.g., Project 0 doesn't count as much as the path tracer.  We will determine the weighting at the end of the semester based on the size of each project.
 
+-------------------------------------------------------------------------------
+SUBMISSION
+-------------------------------------------------------------------------------
+As with the previous project, you should fork this project and work inside of your fork. Upon completion, commit your finished project back to your fork, and make a pull request to the master repository.
+You should include a README.md file in the root directory detailing the following
 
+* A brief description of the project and specific features you implemented
+* At least one screenshot of your project running, and at least one screenshot of the final rendered output of your raytracer
+* Instructions for building and running your project if they differ from the base code
+* A link to your blog post detailing the project
+* A list of all third-party code used