PERFORMANCE EVALUATION OF NUMPY, SCIPY, PYMEL AND OPENMAYA COMPARED TO THE C++ API IN AUTODESK MAYA
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Bachelor of Science in Digital Game Development
June 2021
Performance evaluation of NumPy,
SciPy, PyMEL and OpenMaya
compared to the C++ API in Autodesk
Maya
Patrik Svensson
Fredrik Galfi
Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, SwedenThis thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfilment of the requirements for the degree of Bachelor of Science in Digital Game Development. The thesis is equivalent to 10 weeks of full time studies. The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identified as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree. Contact Information: Author(s): Patrik Svensson E-mail: pasv18@student.bth.se Fredrik Galfi E-mail: frga18@student.bth.se University advisor: M.Sc. Viktor Kelkkanen Department of Computer Science Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57
Abstract Background. Autodesk Maya allows scripting through both MEL and Python, and it is also possible to use different Python modules and a C++ API to perform the desired tasks. In theory, the C++ API is the fastest option in Maya, but there are no studies that support this claim. Other studies show that PyMEL is the slowest module in Maya to work with, but it is still the one used most frequently. This the- sis has therefore made a speed measurement to determine which of the four selected Python modules and the C++ API is the fastest to use, regarding animation transfer between skeletal hierarchies with different numbers of data. Objectives. The aim of this thesis is to measure the performance in terms of speed of the Python modules NumPy, SciPy, OpenMaya and PyMEL, as well as the C++ API, in order to determine which is the fastest. Our objectives are to determine the speed performance of each module by conducting experiments. Methods. To achieve the objectives, an experiment was conducted to compare the speed of each Python module and the C++ API. To perform the experiments, the implementations for each module and the API have been written in the same way, with their own data types and classes. After performing the experiments for each module, the mean time consumption of each program has been compared. Results. The results from the experiments show that there was a noticeable dif- ference in the speed between the C++ API and the Python modules, as the C++ API delivered the highest speed for all the skeletons that took place in the exper- iments. The OpenMaya module was the fastest Python module that was tested, while PyMEL was the slowest. The C++ API’s measurements show that it took 0,388–1,909 seconds depending on which skeleton was used to perform the experi- ment, while OpenMaya’s measurements were 0,538–3,119 seconds which show that OpenMaya is 39–68% slower than the C++ API. NumPy, SciPy and PyMEL’s mea- surements ranged from 689 % to 3165 % slower than the C++ API. Conclusions. The conclusion of the experiments show that the C++ API is the fastest to use, while PyMEL is the slowest module, as it is 2632–3165 % slower, when used for these animation transfers. This shows that the C++ API can be a better choice for complex calculations, such as animation transfers. Keywords: Animation transfer, Performance, Scripting, Python
Acknowledgments
As authors of this thesis, we would like to thank our supervisor during the project,
Viktor Kelkkanen. We would also like to thank Christoffer Karlsson for sharing his
motion capture animation, where parts of that animation have been used for the
skeletons in our experiments.
iiiContents
Abstract i
Acknowledgments iii
1 Introduction 1
1.1 Thesis purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 NumPy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 SciPy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 OpenMaya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.4 PyMEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.5 C++ API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.6 Excluded languages and modules . . . . . . . . . . . . . . . . 4
1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 5
3 Method 7
3.1 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Research method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Literature review . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Experiment device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Results and Analysis 13
4.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Scaling of the speed . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Discussion 17
5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Conclusions and Future Work 21
6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A Results 27
B Code 31
vC Supplement information 37
C.1 Isolation of the keyframe . . . . . . . . . . . . . . . . . . . . . . . . . 37
C.2 Conversion to standard coordinate space . . . . . . . . . . . . . . . . 37
C.3 Conversion to target joint space . . . . . . . . . . . . . . . . . . . . . 37
C.4 Final rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
viList of Figures
3.1 Test skeletons for the experiments. . . . . . . . . . . . . . . . . . . . 10
4.1 Mean value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 A diagram showing how the time between each skeleton scales for each
module and the C ++ API. . . . . . . . . . . . . . . . . . . . . . . . 14
B.1 Allocate memory for OpenMaya . . . . . . . . . . . . . . . . . . . . . 32
B.2 Transfer function for OpenMaya . . . . . . . . . . . . . . . . . . . . . 33
B.3 Loading the hierarchies for OpenMaya . . . . . . . . . . . . . . . . . 34
B.4 Animation data for source skeleton for OpenMaya . . . . . . . . . . . 34
B.5 getParentsMatrix function for OpenMaya . . . . . . . . . . . . . . . . 35
B.6 Animation data for target skeleton for OpenMaya . . . . . . . . . . . 35
viiList of Tables
4.1 A table that shows how much faster the C++ API is compared to the
Python Modules on each skeleton. . . . . . . . . . . . . . . . . . . . . 13
4.2 Experiment Statistics (values in seconds) . . . . . . . . . . . . . . . 15
4.3 Scaling of speed statistics between skeletons . . . . . . . . . . . . . . 16
A.1 Variables produced for PyMEL with the descriptive statistics tool in
Excel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.2 Variables produced for C++ API with the descriptive statistics tool
in Excel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3 Variables produced for OpenMaya with the descriptive statistics tool
in Excel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4 Variables produced for NumPy with the descriptive statistics tool in
Excel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.5 Variables produced for SciPy with the descriptive statistics tool in
Excel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ixChapter 1
Introduction
Autodesk Maya software is an industry standard, widely used in gaming companies
for 3D modeling, rigging, animation, visual effects and more [10].
The entire Maya interface is built by scripts from a script editor and all of their
functionalities run in the background of Maya’s instance. Usually, this is the way
users use Maya when creating something, as you only need to press a key to perform
its task. The advantage of Maya is that one can use the scripting editor to create one’s
own scripts. These scripts can be written using Maya’s built-in scripting language
called Maya Embedded Language (MEL) and Python. Scripting is used to speed
up work and enable the user to perform the same operation with a single keystroke.
Maya also has the advantage of importing various Python modules if desired for
use in its scripts. Depending on what operation one wants to perform, whether it
is calculations or just transfers of values, it can be beneficial to know which of the
languages or modules to use, as several operations with complex calculations can
more or less be time-consuming depending on the language.
One of the most time consuming tasks of a pipeline for game creation is considered
to be the process of creating an animation for a character [8][25]. Depending on
how complex the animation is, the whole process can take several days for just one
character, depending on what you want to accomplish [8]. It is also common in video
games that several different characters use the same kind of animation, such as a
walk cycle or jumping animation. But recreating the same animation for several
characters is something that ideally should be automated to save time. An example
of this can be read in an article where 26 people created a game that contains two
characters where each character has a walk, idle and attack animation that took
about 50 hours to perform [13]. If one were to perform animations by hand for ten
of these characters, it can take many hours where one could have performed other
tasks instead, which in turn leads to the entire project being extended by several
hours. Instead of recreating the animation, animation data can be transferred from
one skeleton to another. This can be done by creating a script that traverses the
hierarchy of a skeleton and transfers the animation data of every joint, to another
skeleton of choice. Several matrix multiplications are typically required to calculate
the new transformations for the new skeleton, which can be a potential bottleneck if
a slow language is used. Therefore, it is beneficial to know which language or module
provides the best performance in terms of animation data, which is the motivation
of this study.
According to The Importance Of Being Earnest’s (TIOBE) website, Python is
one of the five most popular programs in the world [21] and several blog posts ranging
12 Chapter 1. Introduction
from 2015 to the present day claim that Python is better than MEL [5][4]. Python
did not exist in Autodesk Maya from the beginning and was not added until Maya
version 8.5 [15] in 2007 and then quickly became a more popular choice of scripting
language in Maya [5][4][9]. In most cases, Python is a slower programming language,
especially when it comes to advanced calculations [28]. To counteract this, Python
offers a number of modules used as accelerators for advanced calculations [14]. These
modules will be further explained in Chapter 1.2.
Regarding which programming language one should use within Maya is a hot topic
on many forums related to Maya or scripting [5][4][9]. While the common conception
among Maya’s users is that Python is slower in general, especially when compared to
the C++ API in Maya, it is also easier to learn with a more straightforward syntax,
making Python the most popular choice nonetheless.
1.1 Thesis purpose
In this thesis, results will be presented on how fast transfers of animation data can
be performed with four different python modules and Maya’s C++ API. This thesis
aims to investigate which language or module is the fastest in terms of calculating
animation data between two skeletons in Maya. In order to complete this investiga-
tion, scripts will be implemented in Maya with each selected Python modules as well
as Maya’s C++ API. These scripts will use the same structure, in order to test the
modules on equal conditions. The scripts will traverse through two skeletons, one
skeleton with an animation and one skeleton without. For every joint in the skele-
tons, the scripts will calculate the animation data and transfer them to the skeleton
that has no animation. Since Autodesk Maya’s website claims that the C++ API
is usually the fastest [2], this thesis could strengthen this statement as the scientific
research to prove this statement is scarce, except a book where they vaguely state
that the C++ API will deliver higher performance than MEL [11].
1.2 Modules
In this section, each of the different modules and libraries that will be used in our
research will be presented. This aims to give a better understanding regarding their
functionalities and limitations.
1.2.1 NumPy
NumPy is one of all Python modules that works especially as an accelerator for vector
and matrix multiplications [16]. The reason why NumPy is considered to be faster
in terms of complex calculations within these data types is, among other things, that
the NumPy functions use homogeneous arrays written in the programming language
C instead of ordinary Python lists [27]. These homogeneous arrays are defined by
the type of data to be used, the size, and the dimension that points to a specific
memory location. However, since NumPy does not come with Maya, it has no access
to Maya’s interface on its own. Therefore, all the data types provided by Maya has1.2. Modules 3 to be converted to the data types supported by NumPy, in order to use them with NumPy’s arrays. 1.2.2 SciPy SciPy is highly similar to NumPy, since it is based on NumPy. The difference between SciPy and NumPy is that SciPy focuses more on scientific mathematical calculations with linear algebra [22]. Unlike NumPy, which contains homogeneous arrays that point to a memory location when it is created, SciPy does not use arrays in this way. Therefore, it is preferable to usually use a combination of Numpy and Scipy for complex calculations. Since SciPy is based on NumPy, it has the same limitations as NumPy when it comes to accessing Maya’s interface. 1.2.3 OpenMaya This is a Python wrapper for Maya’s C++ API. This library is mainly used to implement more complex scripts that cannot be implemented with just Python. The library is available in two different versions, 1.0 and 2.0, and uses the same structure as the C++ API with its functions, but with Python syntax instead. The latest version of OpenMaya is currently under development but is available and can be used. OpenMaya is claimed to have a better performance with approximately three times the speed of version 1.0 [3]. OpenMaya offers a lot more functionality, but since it is a wrapper for the C++ API, its syntax can be regarded as complex in comparison to other Python modules, and a lot more code can be needed to perform a task compared to PyMEL. OpenMaya’s complex nature is often a topic in discussions on forums, surrounding Maya and its scripting capabilities [24]. 1.2.4 PyMEL PyMEL is a Python module that basically makes Python work properly in Maya. This is because the module offers MEL commands with a Python syntax [19]. The MEL commands make sure that Python can access Maya’s interface, such as func- tionalities and objects in the scene. This also makes PyMEL act slower than pure MEL [18]. 1.2.5 C++ API The C++ API is said to be the strongest and most flexible language to use in Maya, as stated by both Autodesk’s website, books and blog posts [11][18][2]. For users who want to make a more advanced program that may be demanding in terms of performance, the C++ API should be used. This is a good choice as the user with the API can reach the low-level core of Maya in ways that MEL and Python can not [2], which in turn gives more flexibility and speed.
4 Chapter 1. Introduction 1.2.6 Excluded languages and modules It is worth noting that MEL could also have been used in this research. However, due to different syntaxes, different structure of joint processing in MEL, this language has been skipped. This is because MEL uses a lot of extra commands to give the same results as the Python modules does because MEL uses all objects as strings in its code. Since the purpose of this research is to have implementations of the same structure on all modules and the C++ API, this could have meant that MEL might not have given a valid result. 1.3 Structure This thesis will in Chapter 2 provide an overview of related work on this topic. Chapter 3 presents implementations of the Python modules, Numpy, SciPy, Open- Maya and PyMEL, as well as the C++ API used to perform the experiments. This chapter shows how the implementations are structured and how the experiments are performed. All code written for each module and C++ API is available on Github [26]. Chapter 4 shows the results of the experiments, where the mean value from the experiment of each skeleton using the various languages is presented. All raw data from the experiments can be found in Appendix A. Along with the results, an analysis of the results is displayed. A discussion of the results is presented in Chapter 5, while potential limitations are discussed in Chapter 5.1. This thesis is concluded while future work is suggested in Chapter 6.
Chapter 2
Related Work
Similar tests were conducted and presented in 2019 by Gustav Pettersson [18], with
an aim to investigate the performance of various scripting languages and modules
in Autodesk Maya. The author presented his results made with Maya Embedded
Language (MEL), PyMEL, OpenMaya and maya.cmds, and found that there is a
difference in performance depending on the task that is performed. While the tests
showed that OpenMaya had the best performance in most cases, it also showed that
MEL could be faster for specific tasks. Furthermore, the author suggested that
further tests could be implemented for a more specific area, in order to yield better
and more direct results for that particular area.
Ami Marowka emphasized that Python in general has a slower performance than
most languages and therefore presented different modules that could improve the
performance of Python in his article “Python accelerators for high-performance com-
puting” [14]. The results of the article shows that when performing matrix multi-
plications, the module NumPy can improve the performance of pure Python by a
factor of 22302 times.
There are some studies that highlight the possibilities to accelerate the speed
of Python for a specific usage, such as scientific, serial and parallel programming
[6][7]. These articles show one or more examples of using the module NumPy as an
accelerator for their work, as well as other high performance modules.
In a comparative study [1], the authors concluded that C++ outperformed Python
in terms of execution time, but Python is better suited for fast prototyping, since one
could perform less code related to the task. Similar conclusions that the performance
of C++ was higher than Python’s, was drawn in an article [29], where the authors
compared Python and C++ in terms of memory usage and time of execution for
various algorithms such as sorting, searching and insertion. However, the article is
listed as a “preprint”, meaning that it has not yet been peer-reviewed, and should
therefore be regarded as such.
The presented related work relates to our thesis in different ways, since we will
both continue on the work from Gustav Pettersson [18] by conducting tests in a more
precise area with OpenMaya and PyMEL when transferring animation data from
one skeleton to another, as well as include the modules NumPy and SciPy, which
are studied in the articles by Ami Marowka [14], Xing Cai, Hans Petter Langtangen,
Halvard Moe [7], A. Boulle and J. Kieffer [6].
5Chapter 3
Method
This chapter will present the research methods used to conduct the speed-performance
comparison necessary to answer the research question. The chapter is divided into
different sections where the implementations and experiments are presented.
3.1 Research question
Research question While performing identical tasks related to animation pro-
cessing using common Python modules compared to C++ API, which of them is the
fastest?
Hypothesis 1 The Autodesk documentation claims that the C++ API will deliver
highest speed in most cases [2], therefore our hypothesis is that the C++ API will
deliver a plug-in with a better speed-performance than any of the Python modules
PyMEL, OpenMaya, SciPy and NumPy. It is worth to consider that this statement
can not be found in the newer versions of the documentation [3], which means that
the statement might not be true anymore.
Hypothesis 2 PyMEL itself uses MEL commands with Python syntax. This
means that Python must call on MEL’s functions to make them work in written
programs. Because of this, it means that this module itself contains two languages.
This makes our second hypothesis that PyMEL will be the slowest module of the
selected Python modules for the project.
3.2 Research method
This section will be divided into several subsections, in order to present our choice of
method. A literature review was first conducted in order to gain valuable informa-
tion regarding the scripting languages Python, MEL and C++. The conclusions of
this literature review is presented in section 3.2.1. It is worth noting that a literature
review would suffice to answer our research question, but the data that was collected
were either too general or lacked experiments, to back it up. Therefore, we chose to
use implementation and experiment as our research methods. The reason why we
chose implementation as our research method, was because we had to create our own
scripts to test our hypotheses. It is worth mentioning that there are other imple-
mentations available to use when it comes to transferring animation data. However,
78 Chapter 3. Method
since the source code is often hidden in such implementations, it is hard to know how
well the implementation has been created. Therefore, it would be difficult to create
similar implementations with a different module or language, which in turn could
affect the performance of the scripts, and therefore the results. Instead, we chose
to create our own implementations, in order to use a structure that would be fit for
all the modules, without being biased towards one or the other. In order to then be
able to measure the speed for each implementation, experiments are conducted with
three skeletons with different numbers of joints and keyframes. Each of the modules
were tested 1000 times, to get a precise result with a low confidence interval. The
implementations and experiments are presented in their respective subsections, 3.2.2
and 3.2.3.
3.2.1 Literature review
In a literature review performed during a previous course, we made a review of what
the most common uses were for Python, MEL and the C++ API. The review also
examined some of the advantages and disadvantages of each language and module,
to be able to understand which of them is the best, in terms of speed-performance.
MEL, Python and C++ can be used for most tasks in Maya, but there are times
when one has to use either MEL or C++, as Python in these cases can lack certain
functionality. MEL and Python both have the same advantage in being interpreted
languages [11][12], which means that they do not use a compiler when reading the
code. Instead, they use an interpreter that reads the code “on the fly”, making simple
and more direct code faster to execute, as it do not need to compile the code before
executing. But the usage of an interpreter is also a weakness, since larger and more
complex code becomes slower to interpret when compared to a compiled language,
such as C++ [11][12].
Something that emerged in the review that forms the basis for the speed perfor-
mance tests conducted in this thesis is the various modules for Python that exists.
Since Python is a slower language than C++ when it comes to complex calculations,
these modules act as an accelerator for various mathematical calculations for Python
implementations. The use of the different modules can give an advantage to Python
in Maya, as this can give the user an opportunity to optimize their calculations. It
also offers flexibility with other data types and functions that do not exist in Maya,
and can therefore offer faster scripts.
3.2.2 Implementations
This subsection aims to present the general idea of how all the implementations are
built. It is worth noting that all of the implementations are structured the same way,
but they still use their own unique classes and functions. The various steps of the
implementations are listed below.
1. Allocate memory for arrays
All of the implementations use their own versions of dynamic arrays, which
means that the array can allocate more memory and grow bigger if needed.
But depending on the array implementation, the allocation for more memory3.2. Research method 9
every time a new item is put into the array can be time-consuming. Therefore,
the implementations first check how many joints each skeleton has and then
allocate the appropriate amount of memory in advance. An example of this
can be seen in Figure B.1, where OpenMaya has been used.
2. For every frame in the animation
In our skeletons, the animations are 50, 100 and 150 keyframes long respec-
tively. To calculate the whole animation, each skeleton much go through its
hierarchy and calculate its data for every frame. This can be seen in Figure
B.2, which shows the main function of the implementation. The loadList func-
tion that is called here is a recursive function that traverse the hierarchy for a
given skeleton and saves the joints in a pre-allocated list. This can be seen in
Figure B.3.
3. Calculate the animation data for the source skeleton
All of the joints are relevant to their parent, therefore the joints rotation and
translation are also relevant to the parent. For example, compare the clavicle
joint of two different skeletons, their respective parent is not the same, therefore
you can not take one value from one skeleton and give it to the other. So in
order to transfer the rotation, the values need to calculated so that the rotation
is relevant to the world space, instead of its parents. Our implementation
solves this by first isolating the keyframe’s rotation to the space of the joint
by multiplying it with the inverse of the bind-pose, which is the equivalent
of the rotation at keyframe 0. Then the rotation needs to be converted to
world space, which can be achieved by multiplying with the orientation of the
joint, the orientation and rotation of all the parents in the hierarchy and the
inverses of these matrices. The result is the rotation in world space, or standard
coordinate space. An example of this can be seen in Figure B.4, and the math
for these calculations can be viewed in Appendix C. The getParentsMatrix
function can be seen in detail in Figure B.5.
4. Calculate the new animation data for the target skeleton
The next step for the implementation is to calculate the rotation in the space
of the target joints. This is done by taking the rotation and orientation for the
current target joint on each frame and calculate the rotation from the target
source relative to the target’s data, as shown in Figure B.6.
5. Add keyframe for each frame
For each final rotation that has been set to the target after the correct rotations
and orientations from both the source and target skeleton have been calculated,
a keyframe is needed on the target skeleton for each frame when the rotations
have changed, which also can be seen on the last line in Figure B.6.
6. Apply data from the source root to the target root
The last thing to do is to apply the source skeleton’s rotation and translation
from the root, to the target skeleton’s root so that the root joint is properly
rotated and translated from the start, which can be seen in the main function
in Figure B.2.10 Chapter 3. Method
Figure 3.1: Test skeletons for the experiments.
3.2.3 Experiments
Three different skeletons were constructed for use in the experiments, each of them
with an increasing amount of joints and keyframes. The skeletons with their data
can be seen in Figure 3.1. The amount of joints and keyframes for each joint are also
the specific variables that will affect the experiments. For the experiment part, each
of the scripts were tested with each of the skeletons, this determines the effect of the
number of joints and keyframes could have an affect on the module performance. All
the actions that took part in the experiment is listed below.
1. Selection of the skeleton and its duplicate that are to be tested
2. Start timer
3. Start the transfer function
4. When the transfer is completed, turn off the timer
5. Print the timed value to a .txt file
6. Reset variables
7. Repeat process 1000 times
In order to present a confidence interval, each of the scripts were tested 1000
times. Only the time consumed for each script to complete its transfer are saved.
The time consumed for restarting the process and printing values were not recorded.
It is also worth noting that the time it takes for Maya to load the plug-in made with
C++ is also excluded from the test, since the timer for the C++ plug-in does not
start until Maya has finished the loading.3.3. Experiment device 11 3.3 Experiment device All of the tests were conducted on the same desktop computer. The specifications for the computer is listed below. • Processor: Intel i7-4790, 3.60GHz, 4 cores • Memory: 24GB, 1866 MHz, DDR3 RAM • Operating system: Windows 10 Pro 64-bit version 20H2 • Software: Maya 2022
Chapter 4
Results and Analysis
A summary of the experiment results for each module and the C++ API is presented
in this chapter. As described in Figure 3.1, the skeleton rigs with the different data
used for this experiment are defined as Skeleton 1, 2 and 3. A composite table made
in Excel shows the results from each test where the mean is presented, which can be
seen in Figure 4.1. In order to increase the feasibility of the results, the confidence
interval with a 99.0% level will also be presented in Table 4.2. For additional details,
all of the variables produced with Excel’s descriptive statistics tool can be observed
in Appendix A.
The mean value of the experiments on Figure 4.1 shows that the slowest Python
module are PyMEL, as it is 20 times slower than OpenMaya and about 30 times
slower than the C++ API. But despite this slow speed, the module itself scales its
own speed as well as the other Python modules and the C++ API. Which means
that all of them slow down when handling more information. This can be seen in
Figure 4.2, where it is possible to see an increase in speed on each skeleton. Each
module and the C++ API’s result shows an increase in speed of ×3 between Skeleton
1 and Skeleton 2, as the total number of keyframes for joints increased by ×3, from
1000 to 3000. Between Skeleton 2 and Skeleton 3 where keyframes have been doubled
further from 3000 to 6000, the speed is roughly doubled for every module and the
C++ API.
The one that turned out to have the best results was C++, which had an execu-
tion time of 0.388 seconds on Skeleton 1, and required roughly ×4,9 times the speed
to execute Skeleton 3, while all of the Python modules required almost ×6 times the
speed of Skeleton 1 to execute Skeleton 3 as shown in Table 4.3.
To show and overview of how fast the C++ API is in percent compared to the
other Python modules, these are shown in Table 4.1.
Module Skeleton 1 Skeleton 2 Skeleton 3
OpenMaya 39% 47% 68%
PyMEL 2632% 2969% 3165%
NumPy 743% 809% 864%
SciPy 689% 745% 802%
Table 4.1: A table that shows how much faster the C++ API is compared to the
Python Modules on each skeleton.
OpenMaya’s results turned out to be almost as fast as the C++ API in seconds
where it only differs by a few deciseconds or seconds, but when you check the values
1314 Chapter 4. Results and Analysis
65
60
55
50
45
40
Seconds
35
30
25
20
15
10
5
0
OPENMAYA PyMEL NumPy SciPy C++ API
Skeleton 1 0.538 10.213 2.884 2.675 0.388
Skeleton 2 1.517 30.732 8.371 7.709 1.035
Skeleton 3 3.119 60.419 16.487 15.318 1.909
Figure 4.1: Mean value.
65
60.419
60
55
50
45
40
35 30.732
30
Seconds
25
20 16.487
15 10.213
8.371 15.318
10
2.884 7.709 3.119
5 1.517
2.675
0 0.538
1.035 1.909
0.388
-5
-10
Skeleton 1 Skeleton 2 Skeleton 3
OpenMaya 0.538 1.517 3.119
PyMEL 10.213 30.732 60.419
NumPy 2.884 8.371 16.487
SciPy 2.675 7.709 15.318
C++ API 0.388 1.035 1.909
Figure 4.2: A diagram showing how the time between each skeleton scales for each
module and the C ++ API.4.1. Analysis 15
in percent, it turns out that C++ is 38% faster on Skeleton 1 and as much as 68%
faster on Skeleton 3.
Both NumPy and SciPy turned out to be almost ×6 slower in seconds than the
C++ API, and around 690–743% on Skeleton 1 and between 800–870% on Skeleton
3.
The confidence interval presented on Table 4.2 for each module shows that all the
modules and the C++ API except PyMEL have been at a 2 ms confidence interval
on Skeleton 1, which means that the results from these measurements have been the
most accurate. Even on Skeleton 2 and 3, the confidence interval on the C++ API
is the lowest, meaning that the C++ API’s result is the most accurate.
Module / API Variable Skeleton 1 Skeleton 2 Skeleton 3
Mean 0.538 1.517 3.119
OpenMaya
CI(99.0%) ± 0.002 ± 0.006 ± 0.017
Mean 10.213 30.732 60.419
PyMEL
CI(99.0%) ± 0.007 ± 0.010 ± 0.031
Mean 2.884 8.371 16.487
NumPy
CI(99.0%) ± 0.002 ± 0.005 ± 0.015
Mean 2.675 7.709 15.318
SciPy
CI(99.0%) ± 0.002 ± 0.005 ± 0.021
Mean 0.388 1.035 1.909
C++ API
CI(99.0%) ± 0.002 ± 0.003 ± 0.005
Table 4.2: Experiment Statistics (values in seconds)
4.1 Analysis
The results from the experiments clearly show that the C++ API is the fastest to use
for these particular skeletons with the number of joints and keyframes. The Python
module that turned out to be the worst was PyMEL, which is in line with the theory
as PyMEL is MEL commands that write with Python syntax. And since Python,
which in theory is a slower language in general and Python’s lists are not quick to
work with, this was expected.
Since OpenMaya basically uses the same classes and structures in the functions
that the C++ API does, but with Python syntax, it can be seen as logical that it
would be almost as fast as the C++ API in seconds. However, since OpenMaya is
39–63% slower based on which skeleton you compare, it is important to note that
this difference in seconds will be higher when comparing an even larger skeleton than
compared in the experiments. The reason why it did not give the same speed is most
likely that Python is used in this module as well. But despite this, it clearly shows
that OpenMaya performed the best of the selected Python modules, compared to
the C++ API.
Although the syntax is basically the same for NumPy and SciPy as it is for
PyMEL, these two are three times faster than PyMEL. The reason for this is most
likely due to the fact that the vectorization in NumPy for the arrays is optimized in16 Chapter 4. Results and Analysis
the background with a pre-compiled C code. Since NumPy is imported with SciPy,
this means that these are basically just as fast. This pre-compilation with the C code
means in this case that one does not need to write as much code to get the same
functionalities as a regular array compared to a ndarray that NumPy uses, which in
turn also means, except being faster, that it contributes to fewer bugs [16].
According to the results from the experiments on the C++ API, the API is the
fastest for all the factors that have been checked, such as the speed for each skeleton
and also the difference for the speed between each skeleton. This most likely has to
do with the fact that it is C++, as it is one of the fastest programming languages in
the world.
4.1.1 Scaling of the speed
To analyze the scaling of the speed between the different skeletons for each module
and the C++ API, this is presented i Table 4.3. In the table, Skeleton 1 is referred to
as "S1", Skeleton 2 as "S2", and Skeleton 3 as "S3". This table presents how many
times the speed has been scaled in decimal form between each skeleton in order to see
which one has been scaled the least and which is the fastest. Note that this scaling
in speed is calculated from the mean values.
Module / API S1 - S2 S2 - S3 S1 - S3
OpenMaya ×2,82 ×2,06 ×5,79
PyMEL ×3,01 ×1,96 ×5,91
NumPy ×2,90 ×1,96 ×5,71
SciPy ×2,88 ×1,98 ×5,72
C++ API ×2,66 ×1,84 ×4,92
Table 4.3: Scaling of speed statistics between skeletons
Table 4.3 shows just like Figure 4.1 that each module and the C++ API between
S1 and S2 increases the speed by around ×3, and that between S2 and S3 it increases
by around ×2 for each module and the C++ API. But as the table shows more exact
figures, it can be seen that the C++ API has the lowest increase in both cases, which
shows that it is the fastest in terms of scaling in this case. Regarding S2 and S3,
note in the table that PyMEL, NumPy and SciPy scale their speeds better than
OpenMaya in relation to their own speed. But since it is about such small decimals,
this is hardly noticeable.Chapter 5
Discussion
With the results presented and analyzed, we can answer our research question and
hypotheses.
While performing identical tasks related to animation processing using common
Python modules compared to C++ API, which of them is the fastest?
The results for all of the three different skeletons in Figure 4.1, shows that the C++
API delivers the highest speed-performance of all the modules, while OpenMaya is
the fastest Python based module. For the smallest skeleton, the C++ API delivered
a result which was 0,15 seconds faster than OpenMaya’s result. One could argue that
the difference is so small that the user would never notice it, but it also shows that
OpenMaya operates with approximately 72% of the C++ API’s performance. The
result supports the claims on Autodesk’s documentation from 2018 [2], where they
state that OpenMaya will operate with 70–80% of the C++ API. When performing
smaller tasks, this is something that the user might not notice, but it could be a
great difference when performing more complex and time-consuming tasks.
It is worth pointing out that since both OpenMaya and the C++ API scale their
speeds differently between all the skeletons, there will be differences in how much
slower OpenMaya is compared to the API with larger skeletons. As our measure-
ments show that OpenMaya increases the speed by ×2,06 between skeleton two and
skeleton three, while the C++ API increases its speed by ×1,84, there will be a
larger difference in percentage for how much slower OpenMaya is compared to the
C++ API.
The result presented in this thesis also manages to answer both of the hypotheses
presented in Chapter 3.1. The result presented in Figure 4.1 shows that the C++
API would deliver best speed-performance. The result also shows that PyMEL was
the slowest module in these tests, which was in line with the second hypothesis.
When comparing the results from the smaller skeleton, PyMEL gave a result which
was approximately 26 times slower than the result from the C++ API. Based on
our own experiences, this also means that when working with a smaller skeleton
that has fewer keyframes than what was used for our experiment, all of the Python
modules including PyMEL would deliver a performance that would be acceptable
for most users. But when used with an even larger skeleton that could take several
minutes to process, PyMEL would most likely deliver a performance that would not
be acceptable. These thoughts can be supported by one of the books [15], where the
authors states that no artist would want to work with a script that takes minutes to
execute.
1718 Chapter 5. Discussion
When comparing PyMEL with SciPy and NumPy, the results show that PyMEL
is approximately 3,5–3,9 times slower than both SciPy and NumPy, on all three skele-
tons. Although, one should consider the fact that SciPy and NumPy do not come
integrated with Maya. Therefore, they do not have any low-level access to Maya’s
interface, making it impossible to access functions such as creating new keyframes,
without using another module for this particular functionality. For their implemen-
tations, functions from PyMEL was used in order to make this possible. If SciPy
and NumPy have had access to their own functions for creating new keyframes, it
is possible that these modules may have been even faster. Although, this is just
speculations and would need further testing to prove.
The presented result is similar to the result that was presented in the thesis by
Gustav Pettersson [18], where PyMEL was presented as the slowest module in Maya,
and OpenMaya was the fastest module for most of the functionalities that was tested.
Gustav Pettersson did not include the C++ API in his tests, as he thought it would
be unnecessary, since Autodesk’s documentation stated that it would be faster than
any other language or module.
While Ami Marowka claimed in his article [14] that NumPy could accelerate
the speed of regular Python code by a factor of approximately 22302, this was not
the case with NumPy or SciPy in our experiment, which saw an increase of just 4–5
times. However, NumPy and SciPy did perform better than PyMEL, but not as good
as expected. Although, it is also important to remember that PyMEL itself is not
regular Python, but a Maya Python module. PyMEL is the module that is the closest
to pure Python when it comes to working inside of Maya, but PyMEL has nonetheless
been improved beyond Python’s performance, by calling MEL commands, which in
turn uses C++ code underneath the surface [20].
All implementations use the advantage of pre-allocating memory for the vectors or
arrays that are being used. In order to receive a wider perspective of the performance
of each implementation, they could also have been tested without the pre-allocation.
This would allow us to analyze if a module has slower arrays than the other modules,
when allocating new memory “on the fly”.
The presented result is also important in terms of sustainability, as it could lead
to better and faster implementations of scripts in C++, scripts that could have been
implemented with a slower module such as PyMEL. In an article regarding energy
efficiency for programming languages [17], the authors showed that faster languages
consumed less energy when calculating various problems.
5.1 Limitations
It is noteworthy that there may be some possible limitations in this study, which
could be addressed in future work.
First, one could argue that this thesis would benefit from testing an implemen-
tation written with MEL, as previous work has shown that MEL can perform better
than both PyMEL and OpenMaya in some cases [18].
Second, the experiment only included animations where the skeleton had the
same number of keyframes on all joints. Instead, animations with different amount
of keyframes on every joint could be included for testing in the future.5.1. Limitations 19
Third, the study focuses on our own implementation of how one could transfer an
animation between skeletons, and it is possible that our selected method might not
yield the best possible speed-performance, as there could be methods better suited
for the work.
Last, it is important to understand that the results presented in this thesis is
not immutable, as the results can change with time. Python is a language that is
constantly updated with newer and faster modules. All of the modules presented
in the project could be improved upon in the future, making the results presented
obsolete. Maya is also updated regularly, along with the C++ API and OpenMaya.
Testing our implementations in a different version of Maya could yield changes to
the results, as different versions of Maya support different versions of both Python
and C++.Chapter 6
Conclusions and Future Work
This chapter concludes our results of each Python module and the C++ API and
discusses potential future work.
6.1 Conclusion
As a conclusion, the results from the experiments in this project have answered our
research question about which of the selected Python modules or the C++ API
is the fastest, when performing identical tasks regarding animation transfer. The
conclusion of this experiment is that the C++ API is faster and is also faster in terms
of scaling the speed between the different skeletons involved in the experiment.
When ranking how much slower the speed of the Python modules are compared
to the fastest, which was the C++ API, the list is as follows:
1. OpenMaya
39–68% slower.
2. SciPy
689–802% slower.
3. NumPy
743–864% slower.
4. PyMEL
2632–3165% slower.
In terms of absolute seconds, the measurements show that the C++ API is around
0,2–1,2 seconds faster compared to the fastest Python module OpenMaya, and de-
pending on which skeleton the measurement was performed on. The slowest Python
module was shown to be PyMEL, which was about 2632% to a maximum of 3165%
slower than the C++ API. These two results from the C++ API and PyMEL show
that our hypotheses was correct, regarding C++ as the fastest option and PyMEL as
the slowest. The fact that the C++ API delivered the highest speed-performance was
expected as books, documentation and various blog posts state this theory [11][2][23].
To further prove which module or the C++ API is faster, a calculation was made
of how much the speed decreases between each experimental skeleton. Also in this
calculation, it can be observed that the C++ API scales better than the four Python
modules. The results from this calculation show that the API is on a scaling at a
speed of ×4,92 between Skeleton 1 and Skeleton 3, while the Python modules are
2122 Chapter 6. Conclusions and Future Work
at almost ×6 in increased time-consumption. Between Skeleton 1 and Skeleton 2 it
turns out that all Python modules and the C++ API scale almost equally well, but
that the API is slightly better as an increase of only ×2,66 took place, while the
other modules were between ×2,88 to a maximum of ×3,01.
These findings are relevant to the field as it shows that the C++ API will deliver a
faster script when transferring animations, and can therefore speed up the animation
workflow for game creation. It is also important as it can lead to more sustainability
in the workflow, since it is shown in previous research that faster programming
languages consume less energy when performing calculations.
6.2 Future work
When examining possible related work, an article was found [17], where the authors
conducted tests with 27 well-known programming languages, in order to measure
their performance regarding energy and memory consumption. Their result shows
that Python requires both more energy and memory to perform the same task as
C++. The study also shows that Python was one of the most energy demanding
languages. For our research, this was beyond our scope. However, it would be
valuable in the future to consider their tests and apply them inside of Maya. Such
tests could determine if the Python modules in Maya demands more energy and
memory than the C++ API, giving the user another reason as to why he or she
should use the C++ API over any Python module. Both professional and non
professional users of Maya could benefit from such work, as it would contribute to a
more sustainable workflow in Maya, by minimizing unnecessary energy consumption.
Another possible work for the future is to do this experiment with several dif-
ferent computers, where these have different hardware. In addition to these speed
measurements, it would have also been possible to control the memory consump-
tion on each computer. Conducting these tests with different hardware could give
valuable insight as to how well the different modules would perform when using a
smaller amount of RAM or CPU cache. Furthermore, it could lead to selecting a
programming language based on available hardware.
To the best of our knowledge, MEL could accomplish all of the steps that the
implementations perform, and could therefore be included for future test, as previous
tests has shown that MEL can deliver a better speed performance than both PyMEL
and OpenMaya in some cases [18].
When transferring an animation between two skeletons, there are other options
that also could be tested, such as the Maya plug-in animImportExport.mll, which
exports the animation data to a file, which in turn is possible to import to a new
skeleton. The plug-in lacks support for differences between the skeletons and would
need to be improved on in order to get a proper result. Testing several implemen-
tations could provide a better view on all the modules, and possibly show that one
module is better than the other, regardless of the chosen implementation.Data availability
All data from the experiments and the code from each implementation can be found
at [26]. If the link is not available, please contact one of the authors at the requested
email addresses listed on the title page, and the information and code will be made
available to you.
23Bibliography
[1] Z. Alomari, O. E. Halimi, K. Sivaprasad, and C. Pandit, “Comparative Studies
of Six Programming Languages,” CoRR, vol. abs/1504.00693, 2015. [Online].
Available: http://arxiv.org/abs/1504.00693
[2] Autodesk, “Maya API introduction.” [Online]. Available: https://help.autodesk.
com/view/MAYAUL/2018/ENU/?guid=__files_API_Introduction_htm
[3] ——, “Maya API introduction.” [Online]. Available: https://help.autodesk.
com/view/MAYAUL/2022/ENU/?guid=Maya_SDK_Introduction_html
[4] ——. MEL vs Python. [Online]. Available: http://discourse.techart.online/t/
mel-vs-python/5150/5
[5] ——. Python vs MEL popularity. [Online]. Available: https://forums.autodesk.
com/t5/maya-programming/python-vs-mel-popularity/m-p/8115858#M8197
[6] A. Boulle and J. Kieffer, “High-performance Python for crystallographic
computing,” Journal of Applied Crystallography, vol. 52, no. 4, pp. 882–897,
August 2019. [Online]. Available: https://doi.org/10.1107/S1600576719008471
[7] X. Cai, H. P. Langtanger, and H. Mor, “On the performance of the Python
programming language for serial and parallel scientific computations,” Scientific
Programming, vol. 13, no. 1, pp. 31–56, January 2005. [Online]. Available:
https://doi.org/10.1155/2005/619804
[8] A. Chang. (2019) The Process of 3D Animation. [Online]. Available:
https://www.media-freaks.com/the-process-of-3d-animation/
[9] CSSociety. MEL vs Python? [Online]. Available: https://forums.cgsociety.org/
t/mel-vs-python/1482110
[10] EDUCBA. Differences between Maya and Blender. [Online]. Available:
https://www.educba.com/maya-vs-blender/
[11] D. Gould, Complete Maya Programming (Volume I) An Extensive Guide to
MEL and the C++ API. San Francisco, CA 94104-3205: Morgan-Kaufmann
Publishers, 2003.
[12] D. Karani, “How does Python work?” [Online]. Available: https:
//towardsdatascience.com/how-does-python-work-6f21fd197888
[13] M. Labschütz, K. Krösl, M. Aquino, F. Grashäftl, S. Kohl, and
R. Preiner. Content Creation for a 3D game with Maya and Unity 3D.
[Online]. Available: https://www.researchgate.net/publication/267417785_
Content_Creation_for_a_3D_Game_with_Maya_and_Unity_3D
[14] A. Marowka, “Python accelerators for high-performance computing,” The
2526 BIBLIOGRAPHY
Journal of Supercomputing, vol. 74, no. 4, pp. 1449–1460, December 2017.
[Online]. Available: https://doi.org/10.1007/s11227-017-2213-5
[15] A. Mechtley and R. Trowbridge, Maya Python for Games and Film: A Complete
Reference for the Maya Python API. Boca Raton, Florida: CRC Press, 2011.
[16] NumPy. (2021, Jan) NumPy - What is NumPy? [Online]. Available:
https://numpy.org/doc/stable/user/whatisnumpy.html
[17] R. Pereira, M. Couto, F. Ribeiro, R. Rua, J. Cunha, J. P. Fernandes,
and J. Saraiva, “Energy efficiency across programming languages: how do
energy, time, and memory relate?” Proceedings of the 10th ACM SIGPLAN
International Conference on Software Language Engineering, vol. 10, no. 1,
October 2017. [Online]. Available: https://doi.org/10.1145/3136014.3136031
[18] G. Pettersson, “A comparison of performance in scripting for con-
tent creation in games,” 2019, retrieved March 30, 2021 from
http://urn.kb.se/resolve?urn=urn:nbn:se:bth-18405.
[19] PyMEL. (2020, Feb) PyMEL for Maya. [Online]. Available: https://help.
autodesk.com/cloudhelp/2018/JPN/Maya-Tech-Docs/PyMel/index.html
[20] ——. (2020, Feb) PyMEL for Maya. [Online]. Available: https://help.autodesk.
com/cloudhelp/2018/JPN/Maya-Tech-Docs/PyMel/why_pymel.html
[21] T. T. S. quality company. Tiobe index for april 2021. [Online]. Available:
https://www.tiobe.com/tiobe-index/
[22] SciPy. (2021, Mar) SciPy - introduction. [Online]. Available: https:
//docs.scipy.org/doc/scipy/reference/tutorial/general.html
[23] C. Society, “Python API vs. C++ API.” [Online]. Available: https:
//forums.cgsociety.org/t/python-api-vs-c-api/1628319
[24] ——. What is the difference between PyMEL and Open-
Maya? [Online]. Available: https://forums.cgsociety.org/t/
what-is-the-difference-between-pymel-and-openmaya/1602326
[25] F. Studios. (2020) The pros and cons of 2D and 3D
Animation. [Online]. Available: https://fablestudios.tv/2020/02/17/
the-pros-and-cons-of-2d-and-3d-animation/
[26] P. Svensson and F. Galfi. Thesis project repository. [Online]. Available:
https://github.com/Pudzz?tab=repositories
[27] S. Verma. (2019, Dec) How fast NumPy really is and why? [Online]. Available:
https://towardsdatascience.com/how-fast-numpy-really-is-e9111df44347
[28] P. Xie. (2020, Jul) How slow is Python compared to C. [Online]. Available:
https://medium.com/codex/how-slow-is-python-compared-to-c-3795071ce82a
[29] F. Zehra, Darakhshan, M. Javed, and M. Pasha, “Comparative analysis of
C++ and Python in terms of memory and time,” retrieved May 15, 2021 from
https://www.preprints.org/manuscript/202012.0516/v1, PREPRINT.Appendix A
Results
PyMEL Skeleton 1 Skeleton 2 Skeleton 3
Mean 10,213 30,732 60,419
Standard error 0,003 0,004 0,012
Median 10,203 30,734 60,406
Mode 10,203 30,750 60,500
Standard deviation 0,084 0,124 0,381
Sample variance 0,007 0,015 0,145
Kurtosis 72,260 20,198 102,666
Skewness 7,714 1,180 8,620
Range 1,079 1,798 5,860
Minimum 10,140 30,265 59,875
Maximum 11,219 32,063 65,735
Sum 10213,451 30731,799 60418,633
Count 1000 1000 1000
Confidence level(99,0%) 0,007 0,010 0,031
Upper CI(99,0%) 10,220 30,742 60,450
Lower CI(99,0%) 10,206 30,722 60,388
Table A.1: Variables produced for PyMEL with the descriptive statistics tool in
Excel.
2728 Appendix A. Results
C++ API Skeleton 1 Skeleton 2 Skeleton 3
Mean 0,388 1,035 1,9092
Standard error 0,001 0,001 0,002
Median 0,385 1,031 1,901
Mode 0,385 1,033 1,895
Standard deviation 0,020 0,039 0,066
Sample variance 0,000 0,001 0,004
Kurtosis 525,994 627,074 670,620
Skewness 20,054 22,752 23,752
Range 0,565 1,111 1,911
Minimum 0,373 1,009 1,872
Maximum 0,938 2,121 3,783
Sum 387,878 1034,823 1908,772
Count 1000 1000 1000
Confidence level(99,0%) 0,002 0,003 0,005
Upper CI(99,0%) 0,390 1,038 1,914
Lower CI(99,0%) 0,386 1,032 1,904
Table A.2: Variables produced for C++ API with the descriptive statistics tool in
Excel.
OpenMaya Skeleton 1 Skeleton 2 Skeleton 3
Mean 0,538 1,517 3,119
Standard error 0,001 0,002 0,006
Median 0,532 1,515 3,094
Mode 0,531 1,500 3,000
Standard deviation 0,019 0,076 0,205
Sample variance 0,000 0,006 0,042
Kurtosis 431,999 137,515 20,050
Skewness 17,205 9,400 2,954
Range 0,517 1,344 2,312
Minimum 0,515 1,421 2,782
Maximum 1,032 2,765 5,094
Sum 538,329 1517,281 3119,173
Count 1000 1000 1000
Confidence level(99,0%) 0,002 0,006 0,017
Upper CI(99,0%) 0,540 1,523 3,136
Lower CI(99,0%) 0,536 1,511 3,102
Table A.3: Variables produced for OpenMaya with the descriptive statistics tool in
Excel.29
NumPy Skeleton 1 Skeleton 2 Skeleton 3
Mean 2,884 8,371 16,487
Standard error 0,001 0,002 0,006
Median 2,875 8,360 16,453
Mode 2,875 8,375 16,422
Standard deviation 0,029 0,058 0,187
Sample variance 0,001 0,003 0,035
Kurtosis 233,090 301,414 55,480
Skewness 11,757 13,219 5,546
Range 0,672 1,469 2,704
Minimum 2,843 8,266 16,234
Maximum 3,515 9,735 18,938
Sum 2883,662 8371,138 16487,407
Count 1000 1000 1000
Confidence level(99,0%) 0,002 0,005 0,015
Upper CI(99,0%) 2,886 8,376 16,502
Lower CI(99,0%) 2,881 8,366 16,472
Table A.4: Variables produced for NumPy with the descriptive statistics tool in
Excel.
SciPy Skeleton 1 Skeleton 2 Skeleton 3
Mean 2,675 7,709 15,318
Standard error 0,001 0,002 0,008
Median 2,672 7,703 15,297
Mode 2,672 7,703 15,328
Standard deviation 0,026 0,067 0,261
Sample variance 0,001 0,004 0,068
Kurtosis 91,077 93,771 616,272
Skewness 5,692 7,604 22,518
Range 0,500 1,093 7,547
Minimum 2,625 7,610 15,062
Maximum 3,125 8,703 22,609
Sum 2674,562 7709,424 15318,036
Count 1000 1000 1000
Confidence level(99,0%) 0,002 0,005 0,021
Upper CI(99,0%) 2,677 7,714 15,339
Lower CI(99,0%) 2,673 7,704 15,297
Table A.5: Variables produced for SciPy with the descriptive statistics tool in Excel.Appendix B
Code
3132 Appendix B. Code
Figure B.1: Allocate memory for OpenMaya33 Figure B.2: Transfer function for OpenMaya
34 Appendix B. Code
Figure B.3: Loading the hierarchies for OpenMaya
Figure B.4: Animation data for source skeleton for OpenMayaYou can also read
