Difference between revisions of "Sudo"
Mateya Lucic (talk | contribs) (→Progress) |
Mateya Lucic (talk | contribs) (→Progress) |
||
| Line 8: | Line 8: | ||
== Progress == | == Progress == | ||
=== Assignment 1 === | === Assignment 1 === | ||
| + | |||
Catmull-Clark Mesh Subdivision | Catmull-Clark Mesh Subdivision | ||
| + | |||
After browsing C++ repositories on GitHub in search for a 3D model viewer application, I came across the following repository: https://github.com/tsong/viewer | After browsing C++ repositories on GitHub in search for a 3D model viewer application, I came across the following repository: https://github.com/tsong/viewer | ||
| + | |||
This repository caught my interest as it was amongst the more straight forward 3D model viewing applications with available source code. | This repository caught my interest as it was amongst the more straight forward 3D model viewing applications with available source code. | ||
| + | |||
Upon compiling and running the application I played around with it to determine any procedures which seemed like they would benefit from an increase in speed. I found that when calling for subdivision the loaded mesh took a very long time to complete. As a result, I’ve decided to take a look at the code which is involved in that process to determine whether it can benefit from parallelizing. | Upon compiling and running the application I played around with it to determine any procedures which seemed like they would benefit from an increase in speed. I found that when calling for subdivision the loaded mesh took a very long time to complete. As a result, I’ve decided to take a look at the code which is involved in that process to determine whether it can benefit from parallelizing. | ||
| + | |||
I made some changes to how the application runs in order to profile only the subdivision procedure. I removed the GUI component, and made it so that the only thing the application would do is load a mesh, and then perform the subdivision 4 times. | I made some changes to how the application runs in order to profile only the subdivision procedure. I removed the GUI component, and made it so that the only thing the application would do is load a mesh, and then perform the subdivision 4 times. | ||
| Line 43: | Line 48: | ||
[[File:Subdivision_indexOf.jpg]] | [[File:Subdivision_indexOf.jpg]] | ||
| − | |||
| Line 52: | Line 56: | ||
Analyzing the code, it can be seen that the call structure goes as following: | Analyzing the code, it can be seen that the call structure goes as following: | ||
| − | -> Scene.subdivide(4) | + | -> Scene.subdivide(4) |
| − | + | -> For(4 steps) { mesh.subdivide() } | |
| − | + | -> For(each face in the current mesh) addFaces() | |
| − | + | -> indexOf() | |
The vast majority of time is being occupied within the addFaces method, where a vast part of that time is occupied getting the index of the edges in the mesh. | The vast majority of time is being occupied within the addFaces method, where a vast part of that time is occupied getting the index of the edges in the mesh. | ||
Revision as of 17:57, 7 October 2015
Contents
Sudo
Team Members
Progress
Assignment 1
Catmull-Clark Mesh Subdivision
After browsing C++ repositories on GitHub in search for a 3D model viewer application, I came across the following repository: https://github.com/tsong/viewer
This repository caught my interest as it was amongst the more straight forward 3D model viewing applications with available source code.
Upon compiling and running the application I played around with it to determine any procedures which seemed like they would benefit from an increase in speed. I found that when calling for subdivision the loaded mesh took a very long time to complete. As a result, I’ve decided to take a look at the code which is involved in that process to determine whether it can benefit from parallelizing.
I made some changes to how the application runs in order to profile only the subdivision procedure. I removed the GUI component, and made it so that the only thing the application would do is load a mesh, and then perform the subdivision 4 times.
Output
Flat Profile
Subdivide Method
AddFace Method
IndexOf Methods
I did not trust the flat profile as it was not accurately reflecting the amount of time that the application took to run, so I used the std::chrono library to measure how long the various functions and sections of code took.
Analyzing the code, it can be seen that the call structure goes as following:
-> Scene.subdivide(4)
-> For(4 steps) { mesh.subdivide() }
-> For(each face in the current mesh) addFaces()
-> indexOf()
The vast majority of time is being occupied within the addFaces method, where a vast part of that time is occupied getting the index of the edges in the mesh.
Parallelizable?
If the code is reorganized to first find whether a vertex or edge exists in the mesh and then separate the ones that exist from the ones that don’t and perform the necessary operations on them separately and in parallel, it could possibly result in an improvement in run-time.
