This assignment builds on from the work you have been doing in the tutorials in this module to implement a 3D renderer.
In the past, software rendering was the only option before the introduction of 3D hardware-accelerated graphics functions. It was once, and still is in some quarters, the challenge of hobbyist groups of programmers to demonstrate their technical ability, and artistic prowess, by producing highly optimised versions of 3D rendered scenes.
You will use your software renderer you have been developing in order to create your own 3D demonstration. Your submission must be a Win32 application written in C++ and use only GDI calls for all graphical functionality (i.e. use of APIs such as OpenGL or DirectX are forbidden). Your submission must clearly demonstrate the use of the features of your software 3D renderer in a creative way.
Please note the following requirements: -
All features implemented must be demonstrated clearly in your submission. You should use code in your submission to control enabling and disabling of the features. Do not provide user controls, etc. Your demonstration must be completely standalone. You will not be given credit for any features in your renderer that are not demonstrated in your submission.
The on-screen text must clearly indicate the current features being demonstrated at all times. This should include the form of rendering being shown (wireframe, flat, Gouraud, etc), what lighting is being demonstrated and any other information you feel would be useful. The objective is that the text should clearly explain what is being shown. You will be given details of how to add text to your display later in the module.
As well as the functionality implemented, the stability, performance and coding style will be graded.
When you submit your assignment for marking, you will also need to submit an implementation log detailing the work you have done in this module towards the assignment. You are to start a diary recording everything you do on the application you are building in this module, starting from 1pm on 4th November 2019 (i.e. immediately after the lecture in week 6). This should include the work you do in the practical sessions for this module, as well as the work you do on your own time. You must record every occasion you work on this application separately. For example, if you work on your application on eight separate occasions in a week, I would expect to see eight entries in your diary for that week.
Each entry in the diary should be in the following format:
Date and time work started
on this session
Amount of time spent working on the application in this session
A description of the work done in this session. If problems are encountered, you should include a brief description of the problem and how you overcame it. You should also describe how you have tested your work.
Your implementation log will be used during the marking of your assessment as an aid to assessing the application you submit.
You must submit a zip file to the submission point on Course Resources by the due date and time.
Your zip file must be named <Your student number>.zip. For example, if your student number is 123456789, then your zip file would be named 123456789.zip.
Please do not use any compression system other than zip (i.e. don’t use .rar, .7z, etc). This is because the tools used to download your submissions for marking and uncompress them only work with zip files.
Your zip file needs to contain the following:
A folder called ‘Standalone’ that contains the Release version of your executable, along with any other files needed in order for your demonstration to run. It is your responsibility to ensure that your demonstration will run from a folder on a machine in MS214 or MS215. In particular, do not hardcode absolute paths to 3D models, textures or any other resources that tie the application to a particular machine.
A folder called ‘Source’ containing the complete Visual Studio 2019 solution. Please remove any unnecessary files before creating your zip file. In particular, delete the hidden .vs folder and any Debug or Release folders. This will significantly reduce the size of the zip file you submit and make it much easier for you to submit.
A copy of your Implementation Log in either Word (.doc or .docx) or PDF format.
A completed copy of the Feature Checklist document that details the features you have implemented.
All submitted assignments for this module will appear in an anonymous format to the Marking Tutor and internal/external moderators. As such you are requested not to identify yourself anywhere within your submitted assignment (e.g. by putting your name in your report or your source code) other than via the use of your student number. This will maintain your anonymity to your Marking Tutor and Internal/External Moderators. The principle behind the usage of anonymous marking of assignments is to reassure students that all assignments are marked in an equitable and unbiased manner, thereby ensuring the maintenance of high academic quality standards within the marking of the assessments.
You are not limited to the features we have looked at in this module. Implementation of additional features will be taken into consideration and awarded extra credit. However, you must only Win32 GDI calls to implement any graphics functionality.
Please refer to the Feature Checklist document for details of what features need to be implemented for each grade level. All features for a particular grade level must be implemented before any other features from higher levels will be considered (for example, back face culling is one of the features required for a grade of 50% or higher. If back face culling or any other feature from that level is not implemented, you will not be able to achieve a grade of greater than 50%).
Within a particular grade level, marks will be given for:
Accurate and efficient implementation of the features
The quality and style of the code
The level of detail and completeness of the Implementation Log.
DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma
Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t
Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th
1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of
1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of