Summarize, in about one paragraph, your approach to the scene graph assignment. How did you structure your code? What's cool about it? Are there parts you weren't able to complete?
Describe your animation and include a screen recording showing it running in real-time:
Describe how you created your animation.
Provide a short overview of how to use your viewer.
Document the command-line arguments that can be used to control your viewer. Include both the command-line arguments required by the assignment statement and any additional arguments you decided to add.
--scene scene.s72 -- required -- load scene from scene.s72Document the keyboard and mouse controls used to control your viewer when run interactively. Note that the controls below are placeholders not requirements.
The purpose of this section is to get you to think critically about your code by providing evidence sufficient to demonstrate to course staff that it works. These thoughts may also help you improve the code as you work on it in A2 and beyond.
Describe, in a few sentences, how your loading code works. Reference function and structure names for us to examine.
(If you have A1-show working, you don't need to provide further evidence here. If you do not, provide some sort of print-outs or other scene statistics to prove that your code can load s72 scenes.)
Describe, in a few sentences, how your display code goes from your internal scene graph representation to triangles being drawn by the GPU. Provide function and structure names for us to examine.
Provide evidence that your code can display s72 scenes. Good evidence: screen shots or movies showing that example scene files load correctly. Choose or generate example scene files sufficient to demonstrate all required features (note that the simplifying assumptions in the assignment mean you do not need to completely implement s72).
Spend some time thinking about corner cases that the provided examples may not test. If you develop a test case for these, include the s72 and b72 files with your report as well.
Describe how your code handles camera handling and switching.
Provide evidence that these interactions work. Possible evidence: a screen recording showing debug, user, and scene camera switching and interactive movement of the debug and user cameras.
Describe, in a few sentences, where your culling test is implemented; how you computed bounding boxes and the camera frustum; and the approach you used in your box-frustum test (draw and include a picture if it makes your explanation easier). Include references to specific functions and structures in your code for us to examine further.
Include, as evidence, a screenshot or video showing that culling is working (e.g., by using a debug camera to show that meshes outside the user camera's view aren't being drawn).
Also include evidence that your culling works on any particularly difficult cases you may have thought up (include .s72 / .b72 files as appropriate).
Demonstrate a scene and camera angle where your culling code improves performance; and demonstrate one where it does not improve performance. Include screen shots and make a chart or graph of median frame times as evidence for the performance impact.
Describe, in a few sentences: how your viewer stores keyframes; and where/how your code handles updated transformations due to animations. Include code and structure references.
Provide evidence that your viewer can play back s72 animation. Make sure to demonstrate that both camera and object animation work, and that animation of scene graph hierarchies work.
Describe for your CPU- and GPU-bottlenecked scenes what your approach was to moving the critical part of the workload to the CPU or GPU, respectively. Include a screenshot of the scenes as well as s72 and b72 files as needed.
Describe how you generated the scenes.
Describe how you tested the scenes -- including any relevant hardware information about the computer(s) you tested on.
Provide evidence that in each scene the CPU- or GPU-part of the workload is, indeed, a bottleneck. Use charts and graphs as appropriate to make your argument.
Write a subsection (<h4>) of this section for every attempted performance improvement. If you attempted no further performance improvements leave this section blank.
In each subsection, include a description of what you tried (including references to your code) and evidence of where (and if) the optimization actually did improve performance. Report -- at a minimum -- frame times for the same scene collected in headless mode with the optimization on and off. Ideally, develop a scene for which the optimization does improve performance and another scene for which it does not.
This is the end of the structured report. Feel free to add feedback about A1 to this section.