Animation Generation Project Plan

Transcription

1 Animation Generation Project Plan Sarah Kushner Neil Castelino Angel Delgado Carlo Rosati Chris Khedoo April 3,

2 Contents 1 Revision History 3 2 Background Features Statement of Work Unity UI prototypes Prototype # Prototype # Infrastructure setup UI Specifications Line drawing Main canvas Toolbar tray Path hierarchy palette UI Test Plan UI Development Core Functionality Specifications Core Functionality Test Plan Core Functionality Development Challenges D Line Drawing General Algorithm Layering of Animations Weekly Defect Reports 8 6 Product Manual Software Resource List Hardware Assumptions 9 9 Schedule Term Term Term Demo 13 2

3 11 Risks Schedule Requirements Technology Management Customer Leaders 14 3

4 1 Revision History Name Date Comment Version All 10/12/15 Initial project plan document 1.0 All 10/19/15 Tightening up details and defining the problem 1.1 All 11/02/15 Adding challenges and reorganizing 1.2 All 01/12/16 Changing schedule for Winter Term 2.0 Sarah 01/19/16 Adding Winter Term Demo section 2.1 Sarah 03/30/16 Adding Spring Term schedule section 3.0 4

5 2 Background 3D animation can be a painstakingly tedious activity. To create a desired animation, animators go through the long process of key framing. Key frames are set positions that define the start and end points of a movement, sequences of poses in time. Typically, animators assign poses to certain frames over time, so that in-between motions can be generated by a computer. To get an accurate animation, artists usually must assign many key frames, then spend time adjusting and editing them to be more precise. The fact that industry professionals take so much time and effort to do this shows that for an amateur or untrained artist, creating good 3D animation is close to impossible. Researchers in the IMAGINE group at INRIA (in Grenoble, France) have noticed this problem. They have made significant progress on a project called ERC Expressive, where they aim to offer more intuitive tools to author 3D digital content. The IMAGINE team has invented a technique for animation called space-time sketching, in which a user can draw a line in the path they want a model to take and it will be animated accordingly. As the character follows the path, its model bends and changes shape in a physically realistic way. Their system currently supports creating different movements with the path such as bouncing, rolling, and twisting. Based on the previous research by INRIA and their paper Space-time sketching of character animation, we want to build a Unity plugin that allows users to animate characters along a sketched path under a set of constraints. 2.1 Features (See more in the Customer Requirements Document) The user will be able to draw a line in 3D space from a selected object to its destination. The hand-drawn line will be used to calculate the motion and direction of the character, and then it will be animated. The animation generated should satisfy two constraints: Be as close to the user-drawn line as possible Be the most realistic animation possible based on the path The user will be able to refine the path using control points and if time allows, editing of path can be done using the over-sketching technique. The user will be able to delete the paths they ve drawn. The user will be able to see the paths they ve drawn by selecting multiple characters at a time. 5

6 If multiple characters have the same skeleton/rig (are copies of the same model), the user can copy and paste animations, by means of copying the paths, to other characters. The user will be able to save and export paths to a file to be re-loaded into the plugin at a later time. This functionality will be presented in the form of a plugin to Unity. 3 Statement of Work 3.1 Unity UI prototypes Both prototypes will focus on drawing the path Prototype #1 The first prototype will be produced in order to help define requirements and provide the foundation for the full plugin. The features of the UI prototype will include the buttons, toolbar, panels, and tools needed to carry out what features we ve described. This will help us identify potential requirements issues early on instead of later down the road. Based on the user s drawing motions, we will generate control points to form a path. We will create a simple toolbar which will feature a pen and mouse tool for drawing and refining the path, respectively Prototype #2 Given an arbitrary set of control points, calculate and draw the B-spline in the viewport. The motivation for this prototype is to implement B-spline calculations for control points generated by user drawing on screen. A few sets of control points will be predetermined and supplied as input for this prototype, so that this prototype is not completion dependent of the first prototype. However in practice the input of the B-spline calculator will be control points generated by the lines drawn by the user in the viewport. The refining and deleting of the path are the next steps past the prototype and make up the UI functionality. This will be done with a separate refine path pen tool. 3.2 Infrastructure setup This includes setting up the repository, automated build setup, and issue tracking software. Our repository of choice will be Github. We will also use Github to keep track of issues that arise during the development of our system. We shall also be using LaTeX to typeset the planning, requirement, and design documents as a standard which will be checked into Github and so we will be able to collaborate on it together and maintain revision history. 6

7 3.3 UI Specifications Specifications relating to the Unity UI and how the user will use to engage with the core functionality. Our prototypes will be used to solidify the specifications. It will show us what can and cannot be done through the UI in the ways we have defined based on limited knowledge Line drawing. The path will be calculated using delta values between the drawn path and the input point, where the input points are (x, y, z) coordinates dropped every t seconds for some predetermined t. The points will be dropped in a plane directly parallel to the viewport. The points can then be further modified. The distance from the viewport for each control point and in relation to each other can be changed using the mouse pointer tool Main canvas. This will be the drawing area where paths are displayed as lines with square control points. Control points can be moved here using the Arrow tool. Paths can be drawn with the pen tool. Paths can be refined by drawing over / on top of already drawn paths using the path refine pen tool Toolbar tray. Located at the top of the window. This toolbar will contain an arrow tool, pen tool, and path refine pen tool Path hierarchy palette. This will include options to show/hide paths, show/fold subtrees and name/rename paths. Triangles will appear next to non-leaf node paths clicking on the triangle will show/hide the clicked paths subtree. 3.4 UI Test Plan The plan on how the UI will be tested and what criteria will correlate to successful implementation. As we go along making the first two prototypes, we can test the UI in phases based on what each prototype entails. The final phase of this testing will be User acceptance testing. 3.5 UI Development A simple toolbar/tray will hold the pen and mouse tools. This toolbar can reside at the top of the interface window. The main window will be the work area, where the paths can be drawn, and edited using the different tools available in the toolbar tray. 7

8 There will be a window to Show/Hide control paths for objects. Paths will be organized in a tree hierarchy. Each path may belong to any one parent path and have any number of child paths. This window will contain one path per line. Child paths will be indented one more indent unit than their parent. Parent paths can be folded such that their child paths are hidden. A triangle will appear to the left of any path that is not a leaf node. The triangle will point up when child paths are folded (hidden) and to the right when unfolded (visible). Paths can be renamed. The user can click the name, which will activate edit mode. Edit mode will use visual cues such as a border surrounding the path name with a contrasting background color. The user can click outside of this border box to exit edit mode or press the Escape or Enter/Return key. 3.6 Core Functionality Specifications We will need to define the specifications relating to the core features of the project. As described later in the UI Development section, we have an initial idea of what we will need to do to implement our idea. After the prototype has been completed, we can go more into detail using the interface features and preliminary development work to show us what can, cannot, and still needs to be done. From there, we can make changes accordingly to the specifications. For example, we may find out through prototyping that the way we imagine the user drawing lines can t be done in Unity. Obviously we would have to modify that feature to fit both what we want and what is possible. 3.7 Core Functionality Test Plan This plan will contain unit tests that need to be used in order to ensure all core functionality requirements are implemented correctly. 3.8 Core Functionality Development Development of the core functionality. Break project development down into smaller pieces of the whole: UI frame (toolbars, tools, modes, buttons), UI functionality (path drawing, refining, copying), and core functionality (the animation generation, math). Develop and test each part independently, working toward finish from the ground up. Project can be stubbed out first with dummy methods. 4 Challenges We have identified what we presume will be the most challenging parts of the project. Through our prototypes, we hope to demonstrate a preliminary use case: The user will be able to draw a 2D line that a 3D snake model will follow. 8

9 4.1 3D Line Drawing The line drawing will be handled by the user interface. At first, we want to allow the user to draw a 2D line using the methods described in the statement of work. Then we will move on to 3D lines, which will include experimenting with ways the user can input the path information intuitively while maintaining precise functionality. 4.2 General Algorithm In order to break down this task, we will first employ a version of it to very basic models (i.e. a snake). The path-following is the main goal. The secondary goal is to have the snake model itself bend (squash and stretch) according to the path and its physical constraints. Once this is working, we can generalize it to work with 3D lines in space and with more accuracy in terms of physical animation. 4.3 Layering of Animations This will be tackled in the end of Winter term/beginning of Spring term, since the previous two points must come before this in development. Once we have the line drawing and the algorithm working, we can begin work on blending animations by means of animation layers. 5 Weekly Defect Reports During development a weekly report will be compiled that will include new defects and progress on existing defects. This is meant to be a tool to assist in timely defect resolution. Solutions to roadblocks and action items relating to defects can be addressed here. 6 Product Manual A manual will need to be produced to assist users and explain the functionality of the product. This manual will contain everything that the user needs to know about how to successfully use our tool this might consist of what the UI will look like, how to use the UI, and output that the user can expect. This manual will also include a setup/installation manual to explain how the user can get started using our tool. 6.1 Software Proper OS to develop Unity plugins (Windows or OSX) Student version of Unity 9

10 Student version of Autodesk Maya Student version of Unreal Engine 7 Resource List 7.1 Hardware Proper hardware and software is listed below to run Unity with best results: Operating System: Windows XP SP2+, 7 SP1+, 8, 10, Mac OS X GPU: Graphics card with DX9 (shader model 2.0) capabilities. Anything made since 2004 should work. 8 Assumptions Users should have general knowledge of how to install Unity and how to navigate the software once executed. 9 Schedule Weeks marked with (F) denote finals week, and weeks marked with (H) denote holidays. 9.1 Term 1 Fall 2015 What we will do and who will do it: Define Project Plan - All, Lead: Sarah Define Customer Requirements - All Define Requirements Specification - All, Lead: Neil Begin Design Specification - All, Lead: Carlo Develop our two prototypes (This way, we can hopefully spot some expected problems noted in Section 11 early on in the process.) - All, Lead: Angel The prototypes require: base Unity project - Neil studying the paper, finding math libraries - Sarah, Chris the GUI - Angel, Carlo control points generation - Sarah, Carlo 10

11 B-spline generation - Neil, Chris Week Date Work Done? 1 09/21/15 Form group 2 09/28/15 Solidify idea 3 10/05/15 Preliminary Plan document 4 (H) 10/12/15 Fix plan document and rethink project idea 5 10/19/15 Start Customer requirements document and Start prototype #1. See Section for details. 6 10/26/15 Finish Customer requirements document and work on prototype #1 7 11/02/15 Requirements specification and work on prototype #1 8 11/09/15 Requirements specification and work on prototype #1 9 11/16/15 Design specification and Start prototype #2. See Section for details. no 10 (H) 11/23/15 Design specification and work on prototype #2 no 11 11/30/15 Finish prototype #2 development 12 (F) 12/07/15 Finalize Requirements 9.2 Term 2 Winter 2016 What we will do and who will do it: Design Specification - All, Lead: Carlo Start core development, Unity is a priority - All, Lead: Angel Iteratively change Requirements and Design as needed based on Prototype - All, Leads: Neil, Carlo Determine if/how we can extend our product in the time remaining - All Release versions of product with limited functionality - All UI development - Angel Begin core development - Chris, Carlo, Sarah, Neil Goals: Start and complete Design Specification 11

12 UI and core development features including: LOA drawing, editing, and saving Spline generation from control points General path following animation Complete and present demo, a simple use case (simple snake model following path) Week Date Work Done? 1 01/04/16 Update Project Plan (Sarah) 2 01/11/16 Refine UI prototype (Angel) Start math/theory research (Sarah, Carlo, Chris) 3 (H) 01/18/16 Design specification (All) Refine UI prototype (Angel) Math research (Sarah, Carlo, Sarah) Create and rig snake model (Sarah) 4 01/25/16 Test current UI features (Angel, Chris) Continue math research (Sarah, Carlo) Finish Design Specification (All) 5 02/01/16 Design Specification due Tuesday Create detailed development plan (Carlo, Sarah) Continue development of UI and existing backend functions (All) 6 02/08/16 Change Design as needed (a note to All) Build core functionality (Chris, Sarah, Neil) 7 02/15/16 Continue core development (All) Prepare demo (All) no 8 02/22/16 Continue core development (All) Prepare demo (All) 9 02/29/16 Continue core development (All) Prepare demo (All) 10 03/07/16 Continue core development (All) 11 (F) 03/14/16 Continue core development (All) 9.3 Term 3 Spring 2016 What we will do and who will do it: Update this plan document - Lead: Sarah Continue and finalize Development - All, Lead: Angel Test Plan Document - All, Lead: Chris Sections: Introduction, Test Items, Software Risk Issues - Neil 12

13 Sections: Features to be Tested, Features Not to be Tested, Approach - Chris Sections: Item Pass/Fail Criteria, Suspension Criteria and Resumption Requirements, Test Deliverables - Carlo Sections: Remaining Test Tasks, Environmental Needs, Staffing and Training Needs - Sarah Sections: Responsibilities, Schedule, Planning Risks and Contingencies - Angel Begin Testing on completed features - All, Lead: Chris Continue and complete Testing on all features - All, Lead: Chris Prepare final release - All Week Date Work Done? 1 03/28/16 Tie up loose ends from last term: write code comments, git merges (Sarah, Neil, Angel) Assign parts for Test Plan Doc (Chris) Organize repositories (Angel, Neil) 2 04/04/16 Get first drafts of Test Plan Doc parts to Chris (All) Tighten up spline smoothing, move it to back end (Sarah) Continue to work on cross platform development (Neil) Rotation point front end (Angel) Rotation point development (Carlo) 3 04/11/16 Compile Test Plan Doc parts, assign edits (Chris) Rotation point front end (Angel) Rotation point development (Carlo) Start animation layering (Sarah, Neil) 4 04/18/16 Edit and finish Test Plan Doc (All) Finish animation layering (Sarah, Neil) Start animation exporting (Chris) 5 04/25/16 Test current UI features (Angel) Test current backend features (Sarah, Neil) Finish animation exporting (Chris) 6 05/02/16 Test remaining features according to Test Plan (All) 7 05/09/16 Test remaining features (All) 8 05/16/16 User Manual (All) 9 05/23/16 User Manual and Final Presentation (All) 10 (H) 05/30/16 Final release (All) 11 (F) 06/06/16 Party? 13

14 10 Demo Our main use case for this project is simple. Given a 3D snake model, the user can draw a path in Unity in which the snake will be physically animated along. Before importing the model to Unity, the character must be rigged, meaning that its skeleton is a complete heirarchy of interconnected bones. Because the model is a snake, the skeleton will also be simple. It will consist of 4-5 joints connected by bones. By the end of Winter Term 2016, our team will have developed the plugin to the point where this functionality is possible. The user will be able to do the following, which our team will show in a comprehensive demo. We will show that it is possible to install the plugin and use it within Unity. We will demonstrate the ability to select the snake model for animation generation. We will show the ability to draw, edit, and delete the path via the UI within Unity. After the animation is generated, the user will be able to watch the animation back and save it. This completes the front-end demo. Once the line is drawn, the program will generate an animation for the snake in 3 dimensional space, demonstrating the back-end functionality. This includes curve fitting to the path, path following of the model, and physically realistic animation of the model. Next term (Spring 2016), the focus will be to refine this animation algorithm if needed to work on more complex models and add animation layering. 11 Risks 11.1 Schedule One or more parts of the project may not work as expected due to its complexity We may have delays due to unforeseen events Project gets rushed and some areas of the project get neglected Team members dont have a set time to meet with the group 11.2 Requirements Requirements may change unexpectedly Requirements are not fully known at the start of the project Some requirements may be neglected as a lower priority but in reality would be a higher priority Projects target audience, focus, or goals change unexpectedly 14

15 11.3 Technology Certain team members have little to no experience with animation which may lead to delays Editor/Development suite may be buggy and lead to delays 11.4 Management Project doesnt get reviewed often and we lose track of our progress Project members havent yet found out the constraints for each problem they might encounter One person assumes the role of multiple management roles 11.5 Customer Customer might want to change the requirements unexpectedly in a major way Customer might want a change in the schedule which the team members cant comply with 12 Leaders This project is broken up into five different sections and each section has been designated a leader, or somebody who is responsible for driving the completion of that section. The leaders for each section are listed below: Project plan: Sarah Kushner Requirements: Neil Castelino Design: Carlo Rosati Development: Angel Delgado Testing: Chris Khedoo 15