<commit_before>\documentclass{article}
\begin{document}
\title{Part II Project proposal (draft)}
\author{<NAME> (mk428)}
\maketitle

The goal of this project is to develop a software tool for 3D character
animation, akin to (but simpler than) the applications used in the
production of movie special effects.


Core requirements

The tool developed in this project should take as input a description
of a deformable polygon mesh bound to a skeleton. The skeleton should
contain anatomical constraints, in particular the range of angles each
joint may reach. The tool should calculate correct deformations of the
mesh for a given valid skeletal configuration and render the deformed
mesh to a screen.

In the next step, the tool should detect collisions within the
deformed mesh, and use the laws of classical mechanics to simulate a
rigid body, thus preventing different parts of the mesh from
intersecting. The simulated physical effects in a core implementation
should include collisions (impulse), friction forces, intertial mass
and gravitational forces. Additional information required for this
simulation (e.g. the mass of body attached to each bone of the
skeleton) should be included in the input file. Internal (muscular)
forces of the skeleton may also be specified as input, enabling the
character to move `out of its own strength'. All physical effects
should be simulated on a time-step basis.


Optional extensions

Extensions to the program aim to take it further in the direction of
tools used by 3D animation artists to create realistic-looking
movements of humans or creatures. Some possible extensions are:

- An inverse kinematics solver, which attempts to find anatomically
  valid and, if possible, `comfortable' skeleton configurations under
  given constraints (e.g. hand in a particular position).

- Basic interaction with other objects: collision avoidance, throwing
  a ball, etc.

- Implementation of an algorithm to merge different concurrent
  animations within one character (e.g. doing something with the hands
  while walking).

- A simple optimizing algorithm implementation which attempts to
  refine a given animation under certain criteria, e.g. to minimize
  the energy requirements while still requiring a particular goal to
  be achieved. This may be a first step in trying to create character
  animations automatically from a given starting and finishing
  position (a far more complex ambition which is beyond the scope of
  this project).


Acceptance criteria

The program must correctly handle the animation of at least one mesh
resembling a human being. The mesh and skeleton need to include only
the main limbs (fingers, face etc. are considered optional). The
animation is correct if the character never enters an anatomically
impossible pose and does not violate the laws of physics.

Screenshots of several animations produced by the program will be
included in the dissertation. For further evaluation, other students
will be shown animations and asked to answer questions on whether they
believe the animation to be correct by the above definition.

In addition to the functional acceptance, the program is expected to
have a sufficiently high run-time performance to calculate animations
on the example mesh in real time with a fluent concurrent graphical
output, an average present-day PC provided.


Non-Goals

To clarify the requirements, I would like to describe some issues
whose solution is {\em not} an objective of this project:

- To achieve realistic graphical results. It is hard to objectively
  measure how realistic an animation looks, and a subjective judgement
  depends on many artistic factors like the quality of the mesh,
  texturing, lighting etc. which are not part of this project. The
  project will therefore be considered a success if the program does
  not produce physically or anatomically impossible animations; higher
  degrees of realism are optional.

- To create an interactive user interface. The tool requires no user
  input beyond the mesh, skeleton, anatomy and animation files.

- To achive scientifically accurate calculations. High-quality
  approximations of the differential equations describing the
  mechanics require advanced numerical methods, which are considered
  to be beyond the scope of this project. Simple approximations are
  sufficient provided they do not lead to obviously wrong results.


Technologies

The main body of the program will be written in Java 1.5. This
language is well suited for the purpose because of its widespread
acceptance, good maintainability and the availability of extensive
libraries. The graphical output will be rendered using the OpenGL
library.

The input data for the program will be encoded in an XML format based
on the format used by the Cal3D library. This has the advantage that
meshes can be created using standard 3D modelling software, and then
subsequently easily converted to input data for my program using
common tools.

The parser and writer for this XML format will probably be
automatically generated Java code, created by an XML data binding tool
I designed during Summer 2005. Although I developed this data binding
tool from scratch, I view it as an external library for the purpose of
this project.


Starting point

Apart from the data binding tool, which serves merely to facilitate
the reading and writing between XML data and Java objects, and the
standard Java runtime libraries, I do not intend to make use of any
external or previously written code. The physics simulation will be
based primarily on my knowledge from Part IA Natural Sciences and
additional reading if necessary. For the collision detection part
of the project, I will search for literature on appropriate algorithms
during the preparation phase.

I would like to create example 3D meshes myself using the Blender
modelling software. I already have a moderate amount of experience
in using this application. I have also done some programming with the
OpenGL libraries in the past; however, this never included deformable
meshes. No additional programming languages will be required.


Timetable

The project timetable aims to complete long before the final deadline
in order to leave additional time for exam revision. It is divided
into 2-week blocks. The completion of the tasks by the end of each
block constitutes a milestone.

10 Oct -- 23 Oct:
    Create 3D model. Read about collision detection algorithms.
    Proposal submission. Revise physics.

24 Oct -- 6 Nov:
    Prepare parser and writer for mesh file format.
    Render undeformed mesh to OpenGL.
    Work out maths of mesh deformation and physics.

7 Nov -- 20 Nov:
    Implement mesh deformation.
    Prepare sample animations.

21 Nov -- 4 Dec:
    Implement collision detection. Test.

5 Dec -- 18 Dec:
    Implement physics. Test.

19 Dec -- 1 Jan:
    Holiday.

2 Jan -- 15 Jan:
    Complete implementation of physics.

16 Jan -- 29 Jan:
    Extension 1.

30 Jan -- 12 Feb:
    Extension 2.
    Evaluation, clean up.
    Progress report.

13 Feb -- 26 Feb:
    Write dissertation.

28 Feb -- 12 Mar:
    Write dissertation.

13 Mar -- 19 Mar: (NB. 1 week)
    Finalize dissertation.

\end{document}<commit_msg>*** empty log message ***<commit_after>\documentclass{article}
\begin{document}
\title{Part II Project proposal (draft)}
\author{<NAME> (mk428)}
\maketitle

The goal of this project is to develop a software tool for 3D character
animation, akin to (but simpler than) the applications used in the
production of movie special effects.

\section{Core requirements}

The tool developed in this project should take as input a description
of a deformable polygon mesh bound to a skeleton. The skeleton should
contain anatomical constraints, in particular the range of angles each
joint may reach. The tool should calculate correct deformations of the
mesh for a given valid skeletal configuration and render the deformed
mesh to a screen.

In the next step, the tool should detect collisions within the
deformed mesh, and use the laws of classical mechanics to simulate a
rigid body, thus preventing different parts of the mesh from
intersecting. The simulated physical effects in a core implementation
should include collisions (impulse), friction forces, intertial mass
and gravitational forces. Additional information required for this
simulation (e.g. the mass of body attached to each bone of the
skeleton) should be included in the input file. Internal (muscular)
forces of the skeleton may also be specified as input, enabling the
character to move `out of its own strength'. All physical effects
should be simulated on a time-step basis.


\section{Optional extensions}

Extensions to the program aim to take it further in the direction of
tools used by 3D animation artists to create realistic-looking
movements of humans or creatures. Some possible extensions are:

\begin{itemize}
\item An inverse kinematics solver, which attempts to find anatomically
  valid and, if possible, `comfortable' skeleton configurations under
  given constraints (e.g. hand in a particular position).

\item Basic interaction with other objects: collision avoidance, throwing
  a ball, etc.

\item Implementation of an algorithm to merge different concurrent
  animations within one character (e.g. doing something with the hands
  while walking).

\item A simple optimizing algorithm implementation which attempts to
  refine a given animation under certain criteria, e.g. to minimize
  the energy requirements while still requiring a particular goal to
  be achieved. This may be a first step in trying to create character
  animations automatically from a given starting and finishing
  position (a far more complex ambition which is beyond the scope of
  this project).
\end{itemize}


\section{Acceptance criteria}

The program must correctly handle the animation of at least one mesh
resembling a human being. The mesh and skeleton need to include only
the main limbs (fingers, face etc. are considered optional). The
animation is correct if the character never enters an anatomically
impossible pose and does not violate the laws of physics.

Screenshots of several animations produced by the program will be
included in the dissertation. For further evaluation, other students
will be shown animations and asked to answer questions on whether they
believe the animation to be correct by the above definition.

In addition to the functional acceptance, the program is expected to
have a sufficiently high run-time performance to calculate animations
on the example mesh in real time with a fluent concurrent graphical
output, an average present-day PC provided.


\section{Non-Goals}

To clarify the requirements, I would like to describe some issues
whose solution is {\em not} an objective of this project:

\begin{itemize}
\item To achieve realistic graphical results. It is hard to objectively
  measure how realistic an animation looks, and a subjective judgement
  depends on many artistic factors like the quality of the mesh,
  texturing, lighting etc. which are not part of this project. The
  project will therefore be considered a success if the program does
  not produce physically or anatomically impossible animations; higher
  degrees of realism are optional.

\item To create an interactive user interface. The tool requires no user
  input beyond the mesh, skeleton, anatomy and animation files.

\item To achive scientifically accurate calculations. High-quality
  approximations of the differential equations describing the
  mechanics require advanced numerical methods, which are considered
  to be beyond the scope of this project. Simple approximations are
  sufficient provided they do not lead to obviously wrong results.
\end{itemize}


\section{Technologies}

The main body of the program will be written in Java 1.5. This
language is well suited for the purpose because of its widespread
acceptance, good maintainability and the availability of extensive
libraries. The graphical output will be rendered using the OpenGL
library.

The input data for the program will be encoded in an XML format based
on the format used by the Cal3D library. This has the advantage that
meshes can be created using standard 3D modelling software, and then
subsequently easily converted to input data for my program using
common tools.

The parser and writer for this XML format will probably be
automatically generated Java code, created by an XML data binding tool
I designed during Summer 2005. Although I developed this data binding
tool from scratch, I view it as an external library for the purpose of
this project.


\section{Starting point}

Apart from the data binding tool, which serves merely to facilitate
the reading and writing between XML data and Java objects, and the
standard Java runtime libraries, I do not intend to make use of any
external or previously written code. The physics simulation will be
based primarily on my knowledge from Part IA Natural Sciences and
additional reading if necessary. For the collision detection part
of the project, I will search for literature on appropriate algorithms
during the preparation phase.

I would like to create example 3D meshes myself using the Blender
modelling software. I already have a moderate amount of experience
in using this application. I have also done some programming with the
OpenGL libraries in the past; however, this never included deformable
meshes. No additional programming languages will be required.


\section{Timetable}

The project timetable aims to complete long before the final deadline
in order to leave additional time for exam revision. It is divided
into 2-week blocks. The completion of the tasks by the end of each
block constitutes a milestone.

\begin{tabular}{|l|l|}\hline
10 Oct -- 23 Oct: &
    Create 3D model. Read about collision detection algorithms. \\
&   Proposal submission. Revise physics.\\ \hline

24 Oct -- 6 Nov: &
    Prepare parser and writer for mesh file format. \\
&   Render undeformed mesh to OpenGL. \\
&   Work out maths of mesh deformation and physics. \\ \hline

7 Nov -- 20 Nov: &
    Implement mesh deformation.
    Prepare sample animations. \\ \hline

21 Nov -- 4 Dec: &
    Implement collision detection. Test. \\ \hline

5 Dec -- 18 Dec: &
    Implement physics. Test. \\ \hline

19 Dec -- 1 Jan: &
    Holiday. \\ \hline

2 Jan -- 15 Jan: &
    Complete implementation of physics. \\ \hline

16 Jan -- 29 Jan: &
    Extension 1. \\ \hline

30 Jan -- 12 Feb: &
    Extension 2.
    Evaluation, clean up.
    Progress report. \\ \hline

13 Feb -- 26 Feb: &
    Write dissertation. \\ \hline

28 Feb -- 12 Mar: &
    Write dissertation. \\ \hline

13 Mar -- 19 Mar: &
    Finalize dissertation. \\
(NB. 1 week) & \\ \hline
\end{tabular}

\end{document}
{'fraction_non_alphanumeric': 0.03720207953548039, 'fraction_numerical': 0.008237121058672608, 'mean_word_length': 4.123486682808717, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6363916', 'n_tokens_mistral': 3613, 'n_tokens_neox': 3348, 'n_words': 2200}