Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
COSC3000 PROJECT REPORT –
COMPUTER GRAPHICS
The following report documents the design processes and choices behind basic computer graphic
visualisations. These visualisations are extended from the concept of TV energy efficiency established
in a previous report and aim to put a new spin on the data analysed.
1 INTRODUCTION
Computer Graphics (CG) –
The science and practice of creating or manipulating images with computers1
It is through this manipulation and generation that we are able to effectively communicate
and see concepts that are outside the scope of our limitations (for example, aspects of the
universe or DNA strands). CG has been integrated in a variety of environments ranging from
scientific to video games and is the central process of further illustrating and extending upon
the data collected and visualised graphically in Project 1.
While the previous preliminary investigation looked into influential factors and how they
affected TV energy efficiency–through graphical visualisations–this report documents the
paths taken to create an interactive ‘Television Constructor’. A variety of CG visualisation
methodologies used to create this demo are achieved through utilising the Python
programming language2 and various associative libraries (Python Imaging Library (PIL)3 and
Open Graphics Library (OpenGL)4).
This idea of a ‘Television Constructor’ originates from the concept of our throw-away
society. As mentioned by the government, greenhouse gas emissions are becoming more
problematic with the increase of more “affordable electrical appliances” (McGee, 2013).
This is evident when browsing through electronic goods stores. The amount of choice
available makes it a challenge for consumers to make the right purchasing decision for a TV
which suits their lifestyles. The ‘Television Constructor’ aims to solve this problem in a
hypothetical universe by letting the consumer see what sort of television is available based on
customisable options (namely CEC, Star Rating, Screen Size, and Screen Tech). The
television is displayed in a virtual lounge room so consumers can see how it looks in a virtual
environment setting before purchasing it (if it happens to be the right TV for them).
The original design of this CG visualisation is highlighted in Appendix D Figure D1.
However due to feedback, knowledge and time constraints a less ambitious version was
extracted and reformed to become the following demo:
Demo 1 The data displayed to the consumer can be dynamically updated to provide user
feedback as they change the size of the TV.
Demo 2 An observable virtual lounge room with the option of modifying the size of the
TV (no data is displayed as the screen size is changed) can be explored to some
degree.
1 (Hobson, 2015)
2 A widely used general-purpose, high-level programming language (Wikipedia, 2015)
3 Adds image processing capabilities to your Python interpreter (Python Imaging Library (PIL), 2005)
4 The computer industry’s standard application program interface (API) for defining 2D and 3D graphic images
(Gumbel & Yasko, 2011)
2
2 METHODS
While there are other programs with the capability to create and render the demo in a more
realistic and efficient manner, the following points further explain the choices behind why the
final decision was to utilise the Python language with associative PIL and OpenGL libraries.
The hardware the CG programs were created on had NVIDIA OpenGL driver support
and Python software already installed.
The weekly learning labs could be conducted in either Python or MATLAB.
Therefore it seemed logical to pick either one of those options. The conclusive factor
was the level of previous programming experience. The knowledge of the Python
language was stronger than that of MATLAB.
The OpenGL Graphics API for Python and the PIL library were referenced in the
examples the weekly labs provided. As a result, it was thought the logical decision to
choose the APIs that were exemplified.
To successfully create this project fit for demonstration purposes, the aforementioned
applications were used to visualise the following key areas:
3D rendered graphics (including textures, models)
Camera
Transformations (models, camera)
Lighting
2.1 3D Model Creation & Texturing
Model Creation
The inspiration for the design of the lounge room and its contents came from Figure A1 in
Appendix A. It was thought to be a design which could encapsulate many of the techniques
learnt during the weeks following the start of this project. The geometric shapes of the
environment objects together with the variety of specularity (shininess) and textures were key
factors. However the implementation of this environment changed pathways many times
along the course of its creation. Because of the simplistic design of the environment, a low
polygon design was seen as the main visual choice. While a complex environment has a more
appealing visual ‘look’, it can consume a lot of computational time rendering high detailed
textures/many vertex points which was not wanted in this demo scenario.
The original course of action–after modelling the environment in Blender–was to export each
individual model as an obj file and import it using an existing program5 into the main Python
generated space. This program was modified to just import and load the models into the
python file without textures. The textures would have been added afterwards using
commands from the OpenGL library. The reason behind this choice was whilst there was
previous experience in modelling, UV-unwrapping and texturing, it was decided on a
personal level that the lessons learned through this project would have been lessened if the
comfort zone was not left.
The decision to model in Blender and texture using OpenGL became a problem as the project
advanced. The existing program was not modified to draw the texels as each vertex of the
model was created. In addition, lag occurred when rotating the imported object in the world.
5 Reading a wavefront .obj file with PyOpenGL: http://youtu.be/di343umywFk
3
As a consequence, all of the models that appear in the demo are created in the python file
with hard-coded vertex points (glVertex3f) using GL_QUADS and GL_POLYGON to
specify the type of primitive shape drawn. Appendix B contains snapshots of original model
created in Blender.
Even though Blender was not used to directly create the demo models, it was still utilised (in
the first half of production) to model the objects. Each vertex was then selected and its
position hard coded in the main program as shown in Figure 1.
Figure 1 Modelling process
Towards the final stages of production, models used in class were transformed and duplicated
to create different objects as a method to save time (Figure 2). The texture coordinates were
the only dimensions which needed to be updated.
Figure 2 In-demo objects with the same frame origin