This week, I put my energy on editing the class diagrams and class documentation according to these new changes on the rendering engine side in the past couple of weeks.
Class documentation has been revised as well. A xml formater will later help produce nice looking docs on the design of the rendering engine part.
Saturday, March 26, 2011
Some fixes on the rendering engine and it's almost the finalized version of the engine
Some updates and fixes on the engine:
1. The engine is now running by default on fullscreen, it's now able to fetch user's machine resolution and configure to fit this resolution to get a best looking of the interface and rendering area.
2. I have made changes on the editing word coordinator axes. It's now much elegant than before, which has got a cone head and thinner sticks, making it easy to select as well.
3. The first two editing ball will be shown to indicate that the user has successfully add the first two control points.
1. The engine is now running by default on fullscreen, it's now able to fetch user's machine resolution and configure to fit this resolution to get a best looking of the interface and rendering area.
2. I have made changes on the editing word coordinator axes. It's now much elegant than before, which has got a cone head and thinner sticks, making it easy to select as well.
3. The first two editing ball will be shown to indicate that the user has successfully add the first two control points.
Working on updating the rendering engine and communicating with other group members
I think this email sending to all group members would be diary to show what I'm doing this week ---
Hi all,
While I'm working on updating the rendering engine and doing some fixes on it, some important things to say again.
1) Please forgive me to say it again: each of us should at least post 6 diaries by week 6.
2) I will upload the "almost finalized" version of our rendering engine tomorrow. The engine will by default run at fullscreen mode, as Luke wants, it will be smart enough to know users' machine resolution and configure to fit it. If user presses Alt + Enter key, the engine switchs back to 1280 * 800, a classic safe resolution that fits most of machines.
3) The rendering engine now will show a control point ball for first two points to let users know they have successfully add the first two points before we render a knot string starting from third point.
4) Jernej, the size of the button bar for you is determined to be 180 * 800.
5) Phil, the updated engine has been implemented with the XML and database code. Besides this, I have made examples for you to insert button related code so that you do not have to worry about those hard things, such as the alpha blending & rendering state. My intention is to save your time and make things easier for all of others. All code between the comments, // for buttons & // end of buttons, is the implemented button related code. The button framework I used is from a famous xna tutorial: http://alecjacobson.com/games/button-tutorial/ http://www.alecjacobson.com/weblog/?p=539 . This button framework has implemented the Up, Over & Click event handling and color changing. Not only that, it has a very nice advantage that it can recognise if your mouse is over or click the irregular textured area and left other transparent area static. This will be very nice feature for you to draw buttons on the top of Jernej's rope-wood ladder. Hope you will like it.
6) I don't think we need to draw a menu like button bar at the top of the rendering area. As talked to Luke, we only need to draw the essential & important buttons on the right hand side. For those minor operation and short keys, we could simple document it in the user manual.
7) So, what is the next most important thing? We need to look into Jernej's work, check to see how many buttons we could have. We need to make the decision: if we only draw 15 buttons, then which buttons are at this high priority. To work it out, I appeal, each of us, while you are testing and playing around with the rendering engine, please list 15 buttons that you think need to put on the button bar. Please send it back to Tim and CC to other group members by Thursday. So that we can disccuss and make final decision with Luke in Thursday meeting.
Kind regards,
Jun
Hi all,
While I'm working on updating the rendering engine and doing some fixes on it, some important things to say again.
1) Please forgive me to say it again: each of us should at least post 6 diaries by week 6.
2) I will upload the "almost finalized" version of our rendering engine tomorrow. The engine will by default run at fullscreen mode, as Luke wants, it will be smart enough to know users' machine resolution and configure to fit it. If user presses Alt + Enter key, the engine switchs back to 1280 * 800, a classic safe resolution that fits most of machines.
3) The rendering engine now will show a control point ball for first two points to let users know they have successfully add the first two points before we render a knot string starting from third point.
4) Jernej, the size of the button bar for you is determined to be 180 * 800.
5) Phil, the updated engine has been implemented with the XML and database code. Besides this, I have made examples for you to insert button related code so that you do not have to worry about those hard things, such as the alpha blending & rendering state. My intention is to save your time and make things easier for all of others. All code between the comments, // for buttons & // end of buttons, is the implemented button related code. The button framework I used is from a famous xna tutorial: http://alecjacobson.com/games/button-tutorial/ http://www.alecjacobson.com/weblog/?p=539 . This button framework has implemented the Up, Over & Click event handling and color changing. Not only that, it has a very nice advantage that it can recognise if your mouse is over or click the irregular textured area and left other transparent area static. This will be very nice feature for you to draw buttons on the top of Jernej's rope-wood ladder. Hope you will like it.
6) I don't think we need to draw a menu like button bar at the top of the rendering area. As talked to Luke, we only need to draw the essential & important buttons on the right hand side. For those minor operation and short keys, we could simple document it in the user manual.
7) So, what is the next most important thing? We need to look into Jernej's work, check to see how many buttons we could have. We need to make the decision: if we only draw 15 buttons, then which buttons are at this high priority. To work it out, I appeal, each of us, while you are testing and playing around with the rendering engine, please list 15 buttons that you think need to put on the button bar. Please send it back to Tim and CC to other group members by Thursday. So that we can disccuss and make final decision with Luke in Thursday meeting.
Kind regards,
Jun
Friday, March 18, 2011
More mouse event handling
Today, I was working on adding more mouse event handling to the rendering
engine, so that the operations using mouse can be much more elegant. Left
click remains the same to do add pints, slecet a control point, and all other
basic operations as usual. The middle mouse wheel scroll is to move a camera
(zoom in or zoom out). Its drag & drop is now being used to move camera to
four directions, Up, Down, Left, and Right, which is same as the operations
using Up, Down, Left and Right arrow key. The right mouse button drag & drop
is now used to rotate the knot objects in the scence.
engine, so that the operations using mouse can be much more elegant. Left
click remains the same to do add pints, slecet a control point, and all other
basic operations as usual. The middle mouse wheel scroll is to move a camera
(zoom in or zoom out). Its drag & drop is now being used to move camera to
four directions, Up, Down, Left, and Right, which is same as the operations
using Up, Down, Left and Right arrow key. The right mouse button drag & drop
is now used to rotate the knot objects in the scence.
User interface testing
To test if our rendering engine is robust enough and check to see what kind of
user interface is good to create, this week I'm working on testing a user
interface. I decided to draw buttons on the right hand side as it looks nice
and needs less changes on the engine code. Each view has now got a text to
indicate which view it is. I think we should have a status bar at the bottom
of the knot rendering area. Three buttons are drawn for the testing: Select,
Add points, and Delete.
user interface is good to create, this week I'm working on testing a user
interface. I decided to draw buttons on the right hand side as it looks nice
and needs less changes on the engine code. Each view has now got a text to
indicate which view it is. I think we should have a status bar at the bottom
of the knot rendering area. Three buttons are drawn for the testing: Select,
Add points, and Delete.
Database stuff and XML
Today I worked with Allen to add the abilities to our rendering engine to
allow saving snapshots to a local xml file and uploading snapshots to an
online database server. Allen's own framework in web programming is impresive.
It has made my life easier. Simply add the compiled framework dll files,
create PointModel, StepModel, LineModel, and KnotModel, corresponding to the
control point, a snapshot, a string, and a knot in the rendering engine. It
can then easily serialize the data to be xml form and database stuff, then
save it, upload it. The deserialization, as well, very easy and nice to use.
Currently, press L key is to save the snapshots and K key is to load a set of
knot snaphots in run time.
allow saving snapshots to a local xml file and uploading snapshots to an
online database server. Allen's own framework in web programming is impresive.
It has made my life easier. Simply add the compiled framework dll files,
create PointModel, StepModel, LineModel, and KnotModel, corresponding to the
control point, a snapshot, a string, and a knot in the rendering engine. It
can then easily serialize the data to be xml form and database stuff, then
save it, upload it. The deserialization, as well, very easy and nice to use.
Currently, press L key is to save the snapshots and K key is to load a set of
knot snaphots in run time.
Texture changing & Snapshot traversal
In yesterday's meeting, Luke wanted us to improve the 3D knot rendering
engine, mainly two things: 1. to allow user to change the texture of the
strings; 2. when in the snapshot mode, an user should not only be able to play
the animation to see how a knot is tied, but also be able to walk through each
snapshot one by one forwardly and backwardly. 4.5 hours of work today, I have
implemented these two functionalites on the engine.
engine, mainly two things: 1. to allow user to change the texture of the
strings; 2. when in the snapshot mode, an user should not only be able to play
the animation to see how a knot is tied, but also be able to walk through each
snapshot one by one forwardly and backwardly. 4.5 hours of work today, I have
implemented these two functionalites on the engine.
Subscribe to:
Posts (Atom)








