Difference between revisions of "User:Vladbogolin/Proposal/DisplayManager"
Vladbogolin (talk | contribs) |
Vladbogolin (talk | contribs) |
||
| Line 131: | Line 131: | ||
=Why BRL-CAD?= | =Why BRL-CAD?= | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=Why me?= | =Why me?= | ||
| − | |||
| − | |||
| − | |||
| − | |||
=Anything else= | =Anything else= | ||
Revision as of 13:39, 26 April 2013
Contents
Personal Information
- Name: Bogolin Simion Vlad
- E-mail address: vladbogolin@gmail.com
- IRC username: vladbogo
Background info
I am a third year student at Polytechnic University of Bucharest, studying computer science. The main areas that I am interested in are: algorithms, computer graphics and operating systems.
Skills
My skills consist in a strong background in algorithms and data structures. As it comes to programming languages I prefer C/C++ and Java.
- Programming languages I have experienced: C/C++, Java, Python, Haskell, Scheme, Matlab, Assembly language, Clips, Prolog.
- Versioning tools: I am quite familiar with Git using with I have developed a team project and SVN which I am currently using to develop a school project.
Projects
- Labirinth: it's a game in which the character is in a maze and he has to find the portal that takes him out.
- Required skill: C++, OpenGL, GLUT, data structures and algorithms.
- SpaceEscape: a game in which the character is in a spaceship and he has to run away from enemies. Unfortunately, he has driven his spaceship in an asteroids filed and has to try to get out avoiding or destroying the asteroids.
- Required skills: C++, OpenGL, GLUT, data structures and algorithms.
- Ants: a Java team projects based on ants game from AIChallenge, developed using Git. Ants is a multiplayer game in which every player is given a small colony of ants. The objective is that the player must find and destroy all enemy ants.
- Required skills: graph algorithms(BFS), data structures and Mini-Max algorithm.
- Other projects: Below you can find a link to a git repository where I have some of my projects. Unfortunately, the README and the comments for them are in romanian because some of them were school projects.
Project Information
Project Title
New Cross-Platform 3D Display Manager
Brief project summary
Create a new cross-platform 3D display manager. A display manager is the primary means with which BRL-CAD interacts graphically with geometry. Basically, the project purpose is to implement a new display manager using Qt/OGRE. This should be done as an extension to BRL-CAD's libdm library. As I am more familiar to OpenGL I think I will choose to implement this in Qt/Ogl.
Description
Basic steps
Even though the purpose of this project is to create a new display manager interface, this cannot be done without being carefull to all features that a DM should support in order to maintain previous functionalities. So this is one of the most important things I plan to have in mind while implementing the new DM (for features to be supported see Features). After this, I can start working effectively and the next step would be to embed Qt with Tk (for more informations see Embed Qt in Tk windows).
When all done, I can start working on the actual operations that need to be supported. Finally, last step would be testing.
Features
Embed Qt in Tk windows
- Step 1: Open
In order to maintain functionality the new DM should be embedded in Tk windows. To do this it is necessary to make all the initializations of the new display manager that uses Qt but to make it in such a way that can be integrated in Tk. In order words, a new Tk_window should be created and also geometry attributes for the window should be specified. Then, the window must be mapped. Meanwhile, Qt/ogl context must be created. As the window is created and the DM initialized, it is ready to be fired up. This should be one of the first steps that must be implemented.
- Step 2: Init
The initialization of the DM consists on adding an event handler that executes when an event occurs and on defining the behaviour of the dm when a command is executed (a command that involves the dm such as “set”). The initialization step is done when mged attaches the dm.
- Step 3: Open framebuffer
In order to have a functional display manager, a framebuffer needs to be opened in order to be used.
- Important aspects:
- One of the most important things that should be considered while doing this is the fact that the DM should be cross-platform. As I recently experienced (on my Operating Systems course) this could be quite tricky but I will try to consider all things that might be problematic from the beginning. This will be solved probably using macros for things that need to be differ on the particular OS it will be used.
- Step 2 and 3 are routines specific to MGED’s use of LIBDM.
Basic operations
Drawing
Drawing is one of the most important operations. Without this operation a new display manager would be useless. When it comes to drawing there should be done some several steps in order to actual draw. First step is to initialize the environment for the draw operation (drawBegin), then do the actual drawing and finally flush the output buffer(drawEnd).
Line Drawing
- After doing all the above steps, drawing a line shouldn’t be so difficult. As I saw in the existing code, the line is drawn using each display manager particular way. So this means that drawing a line needs to call the Qt appropriate function with the actual values stored in struct dm.
Text Drawing
- Text drawing should be done in the same way Line Drawing is done. As I researched in Qt a string can be drawn inside a rectangle or from a point.
Keyboard mouse integration
Embedding a framebuffer window
Testing
In order to make a good project writing code is just not enough so I will highly focus on testing. First of all I plan to do a step by step test, meaning that after every new feature implemented will be tested. After the project is implemented (hopefully with at least 2-3 weeks before the deadline) I will focus just on testing.
One of the top features of the display manager is to be cross-platform, so I will test it on multiple platforms. At the moment I have installed two Linux distribution (32 and 64 bits), and also Windows (7 and 8, 64-bits) so testing will be on this three platforms. If, after consulting with my mentor, we decide that there is a particular distribution on which I should test the DM, there would be absolutely no problem testing on it.
Testing will consist mostly in creating and loading different models in the new display manager.
Documentation and links on algorithms
Deliverables
The project can be divided in at least 5 parts, so this can be considered a specific measurable goal. I plan to deliver a patch at the end of each phase. I will primarily work on linux and at the end of each phase I will test the code also on Windows and make the necessary changes.
The first patch should include the integration of Qt in Tk windows. Then, after performing every basic action I will submit another patch with each added action. Finally, I will test the entire application cross-platform, but of I plan to make lots of test on the way.
Schedule
This is a rough plan that I am I sure I will be able to follow. I hope I would be able to deliver the patches earlier than scheduled. As planned the project should be ready with at least 2 weeks before the final
- Week 1 (17 June - 24 June): Look even more on the code to see everything that might have missed while during the proposal. I plan to look until the official starting date but I do not know if I will have time because this period overlaps with my exams period so I will be busy. If I will consider that everything is understood, I will start working effectively and writing code.
- Week 2-3 (24 June - 8 July): During this time I plan that Qt will be embedded in Tk and submit the first patch. This time includes at least one day of testing.
- Week 4 (8 July - 15 July): This week is reserved on implementing the drawing line functionality. At least at the end of this week the second patch should be delivered.
- Week 5 (15 July - 22 July): This week is reserved on implementing the drawing text functionality. At least at the end of this week the third patch should be delivered.
- Week 6 (22 July - 29 July): Preparing mid-term evaluation
- Week 7 - 9 (29 July - 19 August): Implementing the keyboard and mouse integration between Qt and Tk. A new patch should be submitted.
- Week 10 - 12 (5 August - 9 September): Embedding a framebuffer window. A new patch should be submitted.
- Week 13 - 14 (9 September - 27 September): Final testing and submitting the final application.
Time availability
I can say without any doubt that I can fulfill the minimum required time of 40 hours / week. As I understood after talking with the community this is quite a complex project so if it will be necessary I could work more. This project is really interesting to me so I will invest as much time as it need in order to complete it.
Known commitments
- Exams: my exam period ends on 14 June so it does not overlap with the official schedule, but I must say that until that I won't be able to start working effectively.
- Vacations: I plan to take about a week of vacation during the summer. Probably there will be some free days after my exams period also. I don't think this is a problem because I plan to take this vacation accordingly to my progress on the project and after consulting with my mentor.
