Project Management

Last updated Jan 18, 2023 Edit Source

• Project management
• Hub
• Index
• Productivity

• Importance of project management for animation students
• What is a pipeline?
• Importance of project conventions.
• Style Guides for project management
• File formats
• Version control and backups
• Communication and working in a team

Production Phases of a typical project

1. Pre-production: This phase includes tasks such as concept development, script writing, storyboarding, and character design. All the necessary information and assets should be gathered, and a production schedule should be created.
2. Production: During this phase, the actual animation is created. This includes tasks such as modeling, texturing, rigging, and animation.
3. Post-production: In this phase, the final animation is polished and prepared for delivery. This includes tasks such as compositing, color correction, sound design, and editing.
4. Final Delivery: The final animation is delivered to the client or uploaded to a distribution platform.
5. Archive: All the assets and files are properly stored, backed up and archived.

1. File Naming: Use descriptive, meaningful and consistent names for all files and folders. Use version numbers, date and initials in the file names. Avoid using spaces or special characters in file names.
2. Folder Structure: Have a clear and consistent folder structure that separates different types of assets, such as character models, textures, and animations. Within each asset folder, have a clear organization for different stages of the asset, such as concept art, modeling, rigging, etc.
3. Version control: Use a version control system such as Git to keep track of changes to the project files over time. This allows for easy collaboration, and the ability to revert to previous versions of the project if necessary.
4. Backup: Regularly backup all project files to an external drive or cloud storage. This ensures that the project files are safe in case of a local drive failure or other issues.
5. File Formats: Use industry standard file formats for all assets, such as PNG or JPG for textures, FBX or OBJ for models, and MP4 or AVI for animations.
6. File organization: Organize files by type, date and version. This will help to find the right file quickly and easily.
7. File resolutions: use appropriate resolution for each type of asset, for example high resolution for final renders, lower resolution for concept art and tests.
8. File compression: Use appropriate compression for each type of file, for example lossless for final renders and lossy for concept art and tests.

1. File Naming:
   • Use all lowercase letters
   • Use hyphens or underscores instead of spaces
   • Use a consistent naming convention, such as “projectname_sequence_shot_version”
   • Include version numbers in the file name`
2. File Organization:
   • Create a clear and consistent folder structure for the project
   • Use folders for different elements, such as characters, environments, and assets
   • Use subfolders for different stages of the project, such as concept art, modeling, animation, and compositing
3. File Formats:
   • Use open, non-proprietary file formats whenever possible
   • Use lossless file formats for all source files
   • Use compressed file formats for final delivery
4. Color Management:
   • Use a consistent color space and bit depth throughout the project
   • Use color charts and color swatches to maintain consistency
   • Use color management tools to ensure consistency across different platforms
5. Version Control:
   • Use a version control system, such as Git, to track changes and collaborate with others
   • Use branches and merge requests to manage different versions of the project
6. Communication and Collaboration:
   • Use a project management tool, such as Asana or Trello, to keep track of tasks and deadlines
   • Use a chat or video conferencing tool, such as Slack or Zoom, to communicate with team members
   • Use a shared drive, such as Google Drive or Dropbox, to share files and collaborate on documents

Here are some file naming dos and don’ts for programming and animation projects:

Dos:

• Use a consistent naming convention: It’s important to use a consistent naming convention for all files in a project. This makes it easier to find and access files, and also makes the project more organized.
• Use meaningful and descriptive names: File names should be meaningful and descriptive, and should clearly indicate what the file contains.
• Use lowercase letters: Lowercase letters are easier to read and less prone to errors than uppercase letters.
• Use hyphens or underscores instead of spaces: Spaces can cause problems with some file systems and programming languages, so it’s better to use hyphens or underscores as word separators.
• Include version numbers: If you’re working on a project that will have multiple versions, it’s a good idea to include version numbers in the file name.

Don’ts:

• Avoid special characters: Special characters such as @, #, $, %, and & can cause problems with some file systems and programming languages, so it’s best to avoid them in file names.
• Avoid using abbreviations: Abbreviations can be confusing and make it difficult to understand what the file contains.
• Avoid using too many numbers, except version numbers: Numbers can be useful for version numbers, but too many numbers in a file name can make it difficult to understand what the file contains.
• Avoid using the same name for different files: It’s important to give different files unique names to avoid confusion and errors.
• Avoid using long names, try to keep them short, and clear.

It’s always a good idea to create a style guide for the project and stick to it to ensure consistency and organization throughout the project.

project file structure example.canvas

File and folder structure is an important aspect of managing programming and animation projects. Here are some dos and don’ts around file and folder structure:

Dos:

• Create a clear and consistent file and folder structure. This can help keep the project organized and make it easier to find and access files.
• Use clear and descriptive naming conventions for files and folders. This can make it easier to understand the purpose of the files and folders.
• Organize files and folders by type or function. For example, you could have a folder for source code, another for assets, and another for documentation.
• Use version control to track changes to the files and folders. This can help you to revert to previous versions of the files if needed.
• Keep a backup of the files and folders in case of a disaster.

Don’ts:

• Avoid using spaces and special characters in file and folder names. This can cause problems when working with certain tools and systems.
• Avoid using overly long or complicated folder structures. This can make it difficult to navigate and find files.
• Avoid using generic names such as “untitled” or “new” for files and folders. This can make it difficult to understand the purpose of the files and folders.
• Avoid having multiple copies of the same files or folders in different locations. This can lead to confusion and inconsistencies.
• Avoid having files or folders with the same name in the same directory. This can lead to overwriting or confusion.

It’s also worth noting that there might be conventions or best practices specific to the animation or programming software, framework or tool that you are using, so it’s worth checking their documentation for more information.

By following these guidelines and creating a clear and consistent file and folder structure, you can help to ensure that your project is well-organized, easy to navigate, and easy to maintain.

A style guide for coding outlines the conventions that should be followed when writing code for a particular project. It can cover things such as naming conventions, indentation, commenting, and more. Here’s an example of what a style guide for coding might include:

1. Naming Conventions:
   • Use clear and descriptive names for variables, functions, and classes
   • Use camelCase for variables and functions, and PascalCase for classes
   • Use consistent prefixes or suffixes to indicate the type of a variable, such as “is”, “has”, “should”
2. Indentation and Spacing:
   • Use consistent indentation levels for code blocks
   • Use spaces around operators and after commas
   • Use blank lines to separate logical sections of code
3. Comments:
   • Include comments for complex or non-obvious code
   • Use clear and concise language in comments
   • Use inline comments to explain the purpose of a specific line of code
4. Functions and Methods:
   • Limit the number of lines in a function to a maximum of 25-30 lines
   • Avoid using global variables and functions
   • Use the single responsibility principle, where a function should have only one purpose
5. Error Handling:
   • Use try-catch blocks to handle errors
   • Use clear and descriptive error messages
   • Avoid using exceptions for flow control
6. Code Reviews:
   • Use code reviews to ensure that the code meets the style guide’s requirements
   • Use code reviews to catch bugs and improve the quality of the code
   • Use code reviews to share knowledge among team members

This is a general example of a style guide for coding, and it can be adjusted to the specific needs of the project, the programming language, and the team. The goal is to have a clear

Here are some specific ways teams work on animated projects:

1. Reviews:
   • Team members typically present their work to the supervisor for review at various stages of production, such as concept art, storyboarding, animation, and compositing.
   • During the review, the supervisor provides feedback and makes suggestions for improvements.
   • Review meetings are usually scheduled at regular intervals, such as weekly or bi-weekly, to ensure that the project stays on track and that any issues are addressed in a timely manner.
2. Planning:
   • Teams typically use project management tools, such as Asana or Trello, to plan and track the progress of the project.
   • The team lead or supervisor creates a schedule for the project and breaks it down into smaller tasks that are assigned to individual team members.
   • Tasks are usually organized by department, such as modeling, animation, and compositing, and are assigned a due date and a priority level.
3. Iterations:
   • Teams typically work in iterations where they complete a set of tasks, review the work, and make changes as needed.
   • Iterations are usually timed, such as one or two weeks, and are used to ensure that the project stays on schedule and that the team is making progress.
   • After each iteration, the team reviews the progress and makes adjustments to the schedule as needed.
4. Collaboration:
   • Team members typically use collaboration tools, such as Slack or Zoom, to communicate with each other and share information.
   • They use cloud-based storage, such as Google Drive or Dropbox, to share files and collaborate on documents.
   • They may use version control system such as git to collaborate on code, documents and assets.
5. Finalization:
   • Once the animation is done, the final stages are color-grading, sound-editing and final compositing.
   • The final animation is then delivered to the client or broadcasted.

These are some common ways that teams work on animated projects, but the workflow can vary depending on the size and scope of the project, the tools and resources available, and the preferences of the team.

Version control is a system that keeps track of changes made to a set of files over time. It allows multiple people to work on the same project simultaneously, and helps to prevent conflicts when merging changes made by different people. In animation projects, version control can be used to track changes to the animation files, such as storyboards, keyframes, and final renders. This can be especially useful when working in a team, as it allows different animators to work on different parts of the project at the same time, while still maintaining consistency and preventing conflicts. Additionally, version control allows teams to roll back to previous versions of the project, in case any errors are introduced or changes need to be undone.

There are several common version control workflows for working on a team, including:

1. Centralized workflow: In this workflow, there is a single “central” repository that all team members push their changes to and pull updates from. This central repository acts as the single source of truth for the project. This is a good workflow for small teams or projects where there is a clear hierarchy of who is in charge of the project.
2. Feature branch workflow: In this workflow, team members create a new branch for each feature or task they are working on, and then merge their changes back into the main branch once they are complete. This allows multiple team members to work on different features simultaneously without conflicts. It also allows for easy rollbacks if a feature doesn’t work as expected.
3. Gitflow workflow: This is a more formal version of the Feature Branch workflow, that adds some additional branches for development, release, and hotfix. This workflow is used in bigger projects and companies where releases are made on a regular basis.
4. Forking workflow: In this workflow, each team member forks a copy of the main repository, and then pushes changes to their own fork. This allows team members to work independently on their own branches without worrying about conflicts. The changes can then be submitted as pull requests to the main repository, which can be reviewed and merged by a designated team member or manager.

Regardless of the workflow you choose, it’s important to have clear communication and guidelines among the team members.

There are several different version control solutions available, including:

1. Git: Git is a distributed version control system that is widely used in the software development community. It is open-source, flexible, and can be used in a variety of different workflows. Git is a command-line based tool, but there are also many graphical user interfaces (GUIs) available that make it easy to use.
2. Mercurial: Mercurial is another distributed version control system that is similar to Git. It is also open-source and can be used in a variety of different workflows.
3. Subversion (SVN): Subversion is a centralized version control system that is similar to Git and Mercurial. It is widely used in enterprise environments and it can be integrated with other tools.
4. Perforce: Perforce is a proprietary, centralized version control system that is widely used in the game development and visual effects industries. It is known for its scalability and performance.
5. Microsoft Team Foundation Server (TFS): TFS is a proprietary, centralized version control system that is developed by Microsoft and is integrated with other Microsoft tools such as Visual Studio. It’s widely used in enterprise environments and can be used for agile development.
6. Visual SourceSafe (VSS): VSS is an older centralized version control system developed by Microsoft that is now considered outdated and replaced by TFS.

These are some of the most common version control solutions, but there are also other lesser-known options available such as BitKeeper, CVS, and RCS. The choice of which version control system to use depends on the specific needs of your project and team.

Git is a distributed version control system, which means that it does not rely on a central server to store and manage the versions of your files. Instead, each team member has a full copy of the entire project repository, including the entire history of all the changes that have been made to it.

Under the hood, Git uses a data model that is based on a directed acyclic graph (DAG) of commits. Each commit in the repository represents a snapshot of the files at a particular point in time, and contains metadata such as the author, the date, and a message describing the changes that were made.

Each commit is identified by a unique SHA-1 hash, which is calculated based on the contents of the commit. This means that if the contents of a commit change, its hash changes as well, making it easy for Git to detect when a change has been made.

When a team member makes changes to a file, they first stage the changes by adding the modified files to the index, which is a temporary area where changes are prepared before being committed. Once the changes are ready, the team member can commit them, which creates a new commit object in the repository and assigns it a unique hash.

Git allows to create branches, which are essentially pointers to different commits in the repository. When a branch is created, it points to the commit that was current at the time it was created. As new commits are made, the branch pointer moves forward to point to the latest commit. This allows multiple team members to work on different features simultaneously without conflicts.

When team members want to share their changes with others, they push their commits to a remote repository, which is a copy of the repository hosted on a server that can be accessed by other team members. Other team members can then pull the changes from the remote repository and integrate them into their own local copy of the repository.

Git uses a three-way merge algorithm to combine changes made by different team members. This algorithm compares the common ancestor of the two branches being merged, the current branch, and the branch being merged. It then applies the changes that were made in the other branch to the current branch, and resolves any conflicts that may arise.

Terminal applications, also known as command-line interfaces (CLIs), function by accepting input in the form of text-based commands. These commands are typed into the terminal and are then executed by the computer.

Commands are usually made up of a command name followed by one or more options, also known as flags or parameters. Flags are usually preceded by a single dash (-) or double dash (–) and are used to modify the behavior of the command. For example, the command ls -l will list the files and folders in a directory in a long format, while ls -a will show hidden files as well.

Flags can be combined together in a single command, for example ls -al will show both the long format and the hidden files.

Some commands also accept arguments, which are additional pieces of information that are passed to the command to specify what it should act on. For example, the command cp file1.txt file2.txt copies the contents of file1.txt to file2.txt, and the command rm file.txt deletes the file file.txt.

Another important aspect of terminal commands is the use of pipes and redirections. Pipes allow to chain commands together and redirect the output of one command to the input of another. For example, the command ls -al | grep "txt" lists all files in a directory and then filters the output to show only the files that contain the string “txt” in their names. Redirection allows to redirect the output of a command to a file or to another command. For example, the command ls -al > files.txt will redirect the output of the command to a file named files.txt.

Some terminal commands also have additional features like tab-completion, which allow to autocomplete commands, filenames and directories by pressing the TAB key.

In summary, terminal applications function by accepting text-based commands, which are usually composed of a command name followed by options (flags), arguments, and sometimes pipes and redirections. These commands can have different options and arguments, and can be combined and chained together to perform more complex tasks.

1. git init: This command is used to initialize a new Git repository. You can use it to start tracking changes to a new project.
2. git add: This command is used to stage changes in a file or a set of files. It’s the first step before committing changes to the repository. When you use this command, you are telling Git to keep track of the changes you made in the files.
3. git commit: This command is used to save the changes you have made to your repository. When you commit, you need to write a message describing the changes you made, so you can understand what you did later.
4. git status: This command is used to check the current status of your repository, it will show you which files have been modified and which files are ready to be committed.
5. git log: This command is used to view the commit history of your repository. It will show you a list of all the commits that have been made, the author, and the commit message.
6. git branch: This command is used to create and manage branches in Git. Branches allow you to work on different parts of your project simultaneously without affecting the main codebase.
7. git checkout: This command is used to switch between different branches in your repository.
8. git merge: This command is used to merge changes made in one branch into another branch. This is useful when you want to combine the work done in different branches.
9. git clone: This command is used to copy a remote repository to your local machine. It allows you to start working on a project that is already hosted on a remote server.
10. git push and git pull: These commands are used to send and retrieve changes to and from a remote repository. git push is used to send your local changes to a remote repository, and git pull is used to retrieve changes from a remote repository to your local machine.

These are the most basic Git commands that you need to know to get started with version control. Remember to always use clear and meaningful commit messages, and to check the status of your repository before and after making changes. Also, don’t hesitate to ask for help if you get stuck or have any questions.

Git and GitHub are related but different technologies.

Git is a version control system (VCS) that allows developers to keep track of changes made to files over time, and to collaborate with other developers on the same codebase. It is a distributed version control system, which means that each developer has a full copy of the entire repository, including the entire history of all the changes that have been made to it.

GitHub, on the other hand, is a web-based platform that provides hosting for Git repositories. It allows developers to store their code remotely and share it with others. It also provides additional features such as issue tracking, pull requests, and wikis.

Git is a command-line tool, which means that it is operated through a terminal or command prompt and users interact with it by typing commands. However, many developers find the command-line interface too difficult to use or too time-consuming. To make things easier, several Git GUI (graphical user interface) tools have been developed.

These Git GUI tools provide a graphical interface that allows developers to interact with Git in a more user-friendly way. They often provide a visual representation of the repository and allow developers to perform common Git tasks such as committing, branching, and merging without having to type commands. Some popular Git GUI tools include:

• GitKraken: A cross-platform Git GUI that offers a visual representation of the repository, and allows developers to perform common Git tasks such as committing, branching, and merging.
• SourceTree: A free Git GUI that offers a visual representation of the repository and allows developers to perform common Git tasks such as committing, branching, and merging.
• GitGui: A simple Git GUI that is included with the Git command-line tool, it provides a simple visual representation of the repository and allows developers to perform common Git tasks such as committing and branching.
• GitX: A Git GUI for Mac OS X that offers a visual representation of the repository and allows developers to perform common Git tasks such as committing, branching, and merging.
• GitExtensions: A Git GUI that integrates with Windows Explorer and offers a visual representation of the repository, and allows developers to perform common Git tasks such as committing, branching, and merging.

These Git GUI tools are not a replacement for Git, but rather an additional layer on top of it. They are designed to make it easier for developers to interact with Git and perform common tasks, but they often rely on the Git command-line tool to perform the actual tasks.

In summary, Git GUI tools are an alternative to the command-line interface, they provide a more user-friendly way to interact with Git, and make it easier for developers to perform common tasks such as committing, branching and merging. However, they rely on the Git command-line tool to perform the actual tasks.

Git-LFS (Large File Storage) is an extension for Git that allows for more efficient storage and management of large files, such as binary files, videos, and images. By default, Git stores all files in their entirety in each commit, which can lead to large repositories, slow performance and difficulties when working with binary files.

Git-LFS addresses this issue by replacing large files with small text pointers in the Git repository, while the actual large files are stored on a separate server. This way, the repository only contains information about the large files, not the large files themselves. When someone clones the repository or checks out a branch, Git-LFS will download the large files automatically in the background.

To use Git-LFS, you need to install it on your machine and configure it to track specific file types. Once it’s configured, when you commit a large file that is being tracked by Git-LFS, it will be replaced by a small text pointer in the repository. When someone else clones the repository, Git-LFS will automatically download the large files in the background.

Git-LFS also provides commands for managing large files such as git lfs ls-files to list the large files in the repository, git lfs track to start tracking a new file type, git lfs untrack to stop

The .gitignore file is a plain text file that is used to specify files or directories that should be ignored by Git. When Git sees a file or directory listed in the .gitignore file, it will not track changes to that file or directory, and will not include it in commits.

This can be useful for ignoring files that are specific to a particular development environment, such as compiled binary files, configuration files, or temporary files. It can also be used to ignore files that contain sensitive information, such as API keys or passwords.

The .gitignore file is typically located in the root directory of a repository, and the syntax for specifying files or directories is based on wildcards. For example, to ignore all files with the .log extension, you would add the following line to the .gitignore file:

*.log

You can also ignore entire directories by specifying the directory name followed by a forward slash. For example, to ignore the “build” directory, you would add the following line to the .gitignore file:

build/

It’s important to note that the .gitignore file applies only to the current repository and will not affect other repositories that you may be working on.

In summary, the .gitignore file is used to specify files or directories that should be ignored by Git, it allows to exclude files that are specific to

examples:

1
2
3
4
5
6
7
8

houdini/mainproject/backup/
Cinematic Vault/.obsidian/workspace

houdini/animatics/backup/

animatics/backup/

.config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

# This .gitignore file should be placed at the root of your Unity project directory
#
# Get latest from https://github.com/github/gitignore/blob/main/Unity.gitignore
#
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/

# MemoryCaptures can get excessive in size.
# They also could contain extremely sensitive data
/[Mm]emoryCaptures/

# Recordings can get excessive in size
/[Rr]ecordings/

# Uncomment this line if you wish to ignore the asset store tools plugin
# /[Aa]ssets/AssetStoreTools*

# Autogenerated Jetbrains Rider plugin
/[Aa]ssets/Plugins/Editor/JetBrains*

# Visual Studio cache directory
.vs/

# Gradle cache directory
.gradle/

# Autogenerated VS/MD/Consulo solution and project files
ExportedObj/
.consulo/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db

# Unity3D generated meta files
*.pidb.meta
*.pdb.meta
*.mdb.meta

# Unity3D generated file on crash reports
sysinfo.txt

# Builds
*.apk
*.aab
*.unitypackage
*.app

# Crashlytics generated file
crashlytics-build.properties

# Packed Addressables
/[Aa]ssets/[Aa]ddressable[Aa]ssets[Dd]ata/*/*.bin*

# Temporary auto-generated Android Assets
/[Aa]ssets/[Ss]treamingAssets/aa.meta
/[Aa]ssets/[Ss]treamingAssets/aa/*

The .gitattributes file is a plain text file that is used to define custom attributes for files in a Git repository. These attributes can be used to specify how Git should handle certain types of files, such as line endings or file permissions.

For example, the .gitattributes file can be used to specify that certain files should be treated as binary files, rather than text files. This can prevent Git from trying to merge changes in those files, which can be useful for binary files such as images or videos.

Another use case is to specify the end-of-line (EOL) conversion for certain files, it can be used to specify how Git should handle line endings on different platforms. For example, you can use the .gitattributes file to specify that all .txt files should have their line endings converted to the Unix-style when they are committed and back to Windows-style when they are checked out.

You can also use .gitattributes file to set file permissions, for example to set the executable permission for a script file.

The .gitattributes file is typically located in the root directory of a repository, and the syntax for specifying file attributes is based on wildcards. For example, to specify that all .txt files should be treated as binary files, you would add the following line to the .gitattributes file:

*.txt binary

It’s important to note that the .gitattributes file applies only to the current repository and will not affect other repositories that you may be working on.

In summary, the .gitattributes file is

Example Files:

This file is for git-LFS and specifies which files should be tracked in LFS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

## Unity ##
*.cs diff=csharp text
*.cginc text
*.shader text
*.mat merge=unityyamlmerge eol=lf
*.anim merge=unityyamlmerge eol=lf
*.unity merge=unityyamlmerge eol=lf
*.prefab merge=unityyamlmerge eol=lf
*.physicsMaterial2D merge=unityyamlmerge eol=lf
*.physicMaterial merge=unityyamlmerge eol=lf
*.asset merge=unityyamlmerge eol=lf
*.meta merge=unityyamlmerge eol=lf
*.controller merge=unityyamlmerge eol=lf
## git-lfs ##
#Image
*.jpg filter=lfs diff=lfs merge=lfs -text
*.jpeg filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.gif filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.ai filter=lfs diff=lfs merge=lfs -text
#Audio
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.ogg filter=lfs diff=lfs merge=lfs -text
#Video
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.mov filter=lfs diff=lfs merge=lfs -text
#3D Object
*.FBX filter=lfs diff=lfs merge=lfs -text
*.collada filter=lfs diff=lfs merge=lfs -text
*.3ds filter=lfs diff=lfs merge=lfs -text
*.gltf filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.blend filter=lfs diff=lfs merge=lfs -text
*.obj filter=lfs diff=lfs merge=lfs -text
*.OBJ filter=lfs diff=lfs merge=lfs -text
*.hiplc filter=lfs diff=lfs merge=lfs -text
*.hipnc filter=lfs diff=lfs merge=lfs -text
*.hip filter=lfs diff=lfs merge=lfs -text
*.otl filter=lfs diff=lfs merge=lfs -text
*.hda filter=lfs diff=lfs merge=lfs -text
*.geo filter=lfs diff=lfs merge=lfs -text
*.bgeo filter=lfs diff=lfs merge=lfs -text
*.clip filter=lfs diff=lfs merge=lfs -text
*.mb filter=lfs diff=lfs merge=lfs -text
*.blend1 filter=lfs diff=lfs merge=lfs -text
#ETC
*.a filter=lfs diff=lfs merge=lfs -text
*.exr filter=lfs diff=lfs merge=lfs -text
*.tga filter=lfs diff=lfs merge=lfs -text
*.pdf filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text
*.dll filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.aif filter=lfs diff=lfs merge=lfs -text
*.ttf filter=lfs diff=lfs merge=lfs -text
*.rns filter=lfs diff=lfs merge=lfs -text
*.reason filter=lfs diff=lfs merge=lfs -text
*.lxo filter=lfs diff=lfs merge=lfs -text
*.ma filter=lfs diff=lfs merge=lfs -text
*.hdr filter=lfs diff=lfs merge=lfs -text
Researchspan>:andspan>:Devlopment/Ben/testing/textures/HDRIspan>:SPACEspan>:ROOMspan>:PACK/nebulaspan>:n0.hdr filter=lfs diff=lfs merge=lfs -text
Main_Project/assets/GEO/FBX/Tri-Speederspan>:(PBRspan>:8K).7z filter=lfs diff=lfs merge=lfs -text

Git-LFS (Large File Storage) and the .gitattributes file are both used to manage the handling of files in a Git repository, but they are used for different purposes.

The .gitattributes file can be used in conjunction with Git-LFS to specify which files should be managed by Git-LFS.

When you use Git-LFS, it will track all the files that match the specified file patterns, by default, Git-LFS will track files that match the following patterns:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

*.jpg 
*.jpeg
*.png 
*.gif 
*.mp4 
*.mkv 
*.avi 
*.mp3 
*.zip 
*.rar 
*.tar 
*.gz 
*.tar.gz 
*.tgz

The .gitattributes file allows you to specify additional file patterns that Git-LFS should track, or to exclude files that should not be tracked by Git-LFS.

For example, you can use the .gitattributes file to specify that all files with the .zip extension should be tracked by Git-LFS:

*.zip filter=lfs diff=lfs merge=lfs -text

This line tells Git-LFS to track all files with the .zip extension, use the lfs filter for diffs and merge and to not consider them as text files.

Additionally, you can use the .gitattributes file to exclude files from being tracked by Git-LFS, for example, if you want to exclude all files with the .log extension:

*.log -filter

This line tells Git-LFS to not track or manage files with the .log extension.

The .gitattributes file can be used in conjunction with Git-LFS to specify which files should be managed by Git-LFS, by specifying additional file patterns that Git-LFS should track or to exclude files that should not be tracked by Git-LFS. This allows you to have more control over the files that Git-LFS will manage and to optimize the storage and performance of your repository.

1. Use Git’s command line interface (CLI) instead of a GUI. The CLI is faster and allows you to quickly execute Git commands without having to navigate through menus.
2. Use Git’s branching feature to work on multiple features or bug fixes at the same time. This allows you to switch between tasks quickly and easily.
3. Use Git’s stash feature to temporarily save changes you’ve made to your code without committing them. This allows you to switch between tasks without losing your progress.
4. Use Git’s stash drop command to discard changes you’ve stashed if you no longer need them.
5. Use Git’s merge command to bring changes from one branch into another. This allows you to keep your branches up-to-date with the latest changes.
6. Use Git’s rebase command to rewrite the history of a branch. This is useful for cleaning up a branch before merging it into another branch.
7. Use Git’s bisect command to find when a bug was introduced in your code. This allows you to quickly pinpoint the problem and fix it.
8. Use Git’s blame command to see who last modified a specific line in a file. This allows you to quickly find out who to ask for help if you need it.
9. Use Git’s hook feature to automate repetitive tasks such as running tests or deploying code.
10. Use Git’s aliases to create custom command shortcuts. This allows you to save time by typing shorter commands.

A terminal, also known as a command line interface (CLI), is a way for users to interact with a computer by typing commands and receiving text-based output. Modern terminals are often graphical and allow users to interact with the computer using a mouse and keyboard.

In the early days of computing, terminals were simply text-based displays that were connected to a computer through a serial cable. Users would type commands into the terminal, and the computer would respond with text-based output. These terminals were used primarily by programmers and system administrators to perform tasks such as running programs and managing files.

As computers have evolved, so have terminals. Modern terminals are often graphical and feature-rich, with support for things like multiple tabs, copy and paste, and even customization of the appearance. They also have the ability to run multiple commands simultaneously and can also run graphical applications.

The history of terminals is linked to the history of operating systems, as the first terminals were used with mainframe computers, then with minicomputers and later with personal computers. With the rise of UNIX and Linux operating systems, terminals became more prevalent and were used for a wider range of tasks. With the rise of Windows and MacOS, the usage of terminals decreased, but still remained important for system administrators. In recent years, with the rise of cloud computing, terminals are becoming more important once again, as more and more people are interacting with remote servers through terminals.

In summary, modern terminals are a way for users to interact with computers using text-based commands, and over time they have evolved to include graphical interfaces, more features, and the ability to run graphical applications.

Here are some homework exercises that can help beginners learn about Git, Git-LFS, and project management for animation:

1. Create a new Git repository for an animation project and experiment with the basic Git commands such as git init, git add, git commit, git status, git log, git diff, git branch, git merge, and git clone.
2. Create a new animation project and use Git-LFS to track and manage large binary files such as image and video files. Experiment with Git-LFS commands such as git lfs install, git lfs track, git lfs ls-files, git lfs pull, and git lfs push.
3. Learn how to use a Git GUI tool such as GitKraken or SourceTree to interact with Git and Git-LFS. Try out different features such as visualizing the repository, creating branches, and merging changes.
4. Create a new animation project and use the .gitattributes file to specify custom attributes for different types of files. For example, specify that certain files should be treated as binary files, or specify the end-of-line (EOL) conversion for certain files.
5. Research different project management tools and techniques for animation projects, such as Trello, Asana, or Jira. Create a project management board for an animation project and experiment with different features such as creating tasks, tracking progress, and collaborating with other team members.
6. Research and learn about different animation workflows and techniques, such as keyframe animation, motion graphics, and 3D animation. Try out different techniques by creating small animation projects and experimenting with different software such as Blender, Maya, or Adobe After Effects.
7. Collaborate with others on an animation project using Git, Git-LFS, and a project management tool. Work on different tasks and merge changes together.
8. Research and learn about different animation production pipelines and how they use Git and Git-LFS to manage and collaborate on animation projects.

By doing these exercises, you will gain a better understanding of how Git, Git-LFS, and project management can be used in animation projects, and be able to apply these tools and techniques to your own animation projects.