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.
For each of the following sections, describe the overall structure of your code, and reference the specific files/functions/data structures that you used. For any parts that are incomplete, discuss what you were able to do and what you tried but couldn't get working.
The purpose of this section is to get you to think critically about your code by explaining it to course staff; these thoughts may help you improve the code as you work on it in A2 and beyond. This section also forms a road map to your code that we can use while grading.
Cover, at least:
what math (vecr/mat/quat) classes and operations you implemented;
any clever approaches to avoid writing duplicated code for, e.g., vec2, vec3, vec4;
how your code gets a window and a swapchain;
how you decided to handle Vulkan resource creation and destruction (e.g., where do pipelines get created? where do they get destroyed?).
Cover, at least: how your viewer stores mesh and scene data; your approach to parsing JSON.
Cover, at least: how your code computes camera transformations; how your code get transformation and vertex data to your shaders.
Include a screenshot of your viewer drawing an example scene.
Cover, at least: what camera controls you decided to implement; where the camera controls are implemented.
Include a screen recording of you moving the camera in a scene.
Cover, at least: your culling approach; what bounding volume you use for meshes and where it is computed.
Include a screenshot or recording 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).
Cover, at least: how your viewer stores keyframes; where your code updates animations; how your code computes elapsed time (if it isn't running in headless mode!).
Include a screen recording showing an animation being played back by your viewer.
Cover, at least: how your code deals with not having a window; how you deal with getting the timestamps from the events file to (e.g.) animation updates; any extra events you decided to support.
Discuss which performance improvements you chose to pursue and how you implemented them.
NOTE: you will demonstrate your performance improvements in the next section.
This section demonstrates that you have tested your code, including finding its limits.
Before getting into the tests, describe here the relevant information about your testing system(s). (CPU, GPU, Memory, driver versions, OS version, ... -- anything you think might be relevant!)
Demonstrate a scene / camera angle where your culling code improves performance; and demonstrate one where it does not improve performance. (If you developed more than one culling method, demonstrate the performance gain/loss from each of them in this section.)
Use charts to summarize performance and graphs to show overall performance. Include screenshots of test scenes.
Demonstrate your code bottlenecking on scene traversal (CPU), vertex processing/assembly (GPU), and fragment processing/write-back (GPU).
Use graphs to demonstrate sensitivity to test scene complexity. Include screenshots of test scenes.
For any other performance improvements you attempted, include comparisons showing them working (or not working). Include screenshots of any test scenes and graphs or charts showing performance differences.
This is the end of the structured report. Feel free to add feedback about A1 (or A0!) to this section.