16 December 2010

Finally managed to fish out the formula that the library uses to calculate the perspective view. In the end, it's the same formula that we used previously. At least now I got my problems narrowed down. Seems like the way we created the perspective view now and the way we did it previously probably has no difference.

Looks like it's the camera that we have set up that is causing the problem. This setting up of the camera is necessary such that we would be able to see the object being loaded without doing an extra translation into the z-axis. Even if the extra translation is done, the object is still not being displayed correctly. Furthermore, without the camera set up, all the objects' animations are not displayed.

Zac and I had a small discussion at around 2p.m. We decided to pause the explode and the pan to translate gesture first. Both of us felt that these 2 functionalities would definitely take quite some time. Hence, we moved on to work on the plane cutting functionality, and the reading of the dicom location information.

I first started out looking for conversion tools that are available to do a dicom to png conversion. Found quite a few, and they only worked on Windows. I tried out a few of them, but none of them worked at all. Some did not even do a conversion, and some conversions gave me png images that looked totally different from the original dicom images.

15 December 2010

Decided to figure out the formula in which the library uses to create the perspective view today. Spent the day studying the methods in the library and how they work. Did some search on the web as well to check on the various ways people create perspective views. Though I did not managed to have any breakthroughs for the pan to translate gesture today, I managed to resolve some issues in the application along the way. It has got to do with the color picking method that we used. We missed out some parts of drawing which caused the display to go haywire at times.

Along the way, Zac and I also had several discussions. We talked about how to go about improving the rotation for both the object as a whole, as well as the individual components. We found the current swipe to rotate being too static, in which every swipe only causes the object to rotate by 45 degrees. Hence, we decided to make use of the pan gesture to do the rotation. Once we got the idea laid out nicely, Zac took over this while I continued to work on the pan to translate gesture.

14 December 2010

Spent the whole day working on the pan to translate gesture. I thought it was going to be fairly simple at first, since we already got the algorithm up in our previous application where we worked with .obj files.

That obviously was not the case. Somehow, the same algorithm does not translate the object we have in the current application properly. From the looks of it, it seems that the final translation value was not enough to produce the same effect that we see in our previous application.

The only difference that I see in both applications is that in the current one, the perspective of the projection matrix is being calculated through the c++ library, and we have the camera set up. In the previous one, we made use of the glFrustumf to create our perspective view.

I spent the whole day trying to work things out, but to no avail. It seems that the formula that we used does not work in our current application at all. Got to spend some more time trying to understand how this whole thing works.

13 December 2010

Started the day by implementing the ModelTransformation class and tweaking our application to cater for that.

At first, both of us expected lots of work to be done in order to get the ModelTransformation class working. However, we got that up fairly quickly before lunch, including the tweaking of the swipe to rotate gesture. I think the fact that we were able to make such changes in such a short time really reflects our understanding of our application.

After lunch, we decided to split the work among ourselves. I worked on the double tap to scale gesture while Zac researched on how to go about implementing the explode functionality. I managed to complete my part at the end of the day. The UIGestureRecognizer is really useful for our application. Managed to get the effect of double tapping a photo in the iPhone's photo application.

06 December 2010 - 10 December 2010

Was sick for the whole week again, and this really affected the pace at which the project is advancing. I tried my best to make up for the lost time.

Managed to get several things working this week. Zac and I worked on the iPad layout together, and I managed to improve how the UIPopoverController animates. The interface for the iPad seems to be on the verge of completion, unless we have to add in new stuff in the future.

Then we started the porting over of the transformation gestures that we have done before. We first started with the swipe to rotate gesture, and got it done without much trouble. However, there was still this issue with the use of the c++ library. There were many warnings given from Xcode highlighting the various different conflicts. Despite these warnings, our project still ran well. But still, we decided to rework our application in such a way that only the EAGLview imports the c++ library.

After some discussions with Kevin, we decided to come up with a ModelTransformation class. This class would contain the different transformations that are being passed over when the gestures are being captured. Then, we would pass in the instance of this class into the EAGLview to perform the necessary transformations.

We decided to leave that to be done on the following week, and went on to set up the SVN on our machines. Having a SVN would definitely save us lots of time.

29 November 2010 - 03 December 2010

Didn't have the chance to blog daily for this week. Been sick for this whole week, and even had to go on MC on the 30th (Tuesday).

I worked on creating the animations for the 3D models for the most of this week. First, I worked with Blender. Got the animations up fairly quickly, but they are just some simple mesh animations. However, the frames got lost when the .dae file is being converted to a .pod via the Collada2POD utility. Tried searching on the web to get help, but couldn't find any. I even resorted to posting on their forum, the PowerVR forums for help. Did not get any reply though, even now.

Hence, I decided to try exporting the model directly into a .pod file. But in order to do that, I would have to work with either Autodesk 3D Studio Max, or Autodesk Maya. Plug-ins are only provided for these 2 modeling tools for exporting to a .pod file. Decided to make use of 3D Studio Max since one of our colleagues have the license for that.

Since 3D Studio Max can only be run on either a Windows or a Linux platform, I had to work with Bernard. He is also the one that has the license for the software. Talked to him for a bit and he allowed me to use the Windows PC at his desk, since he would be going for a course for 2 days. It was really nice of him.

But after that, Kevin ran bootcamp on the MacBook Pro and there is Windows installed. So instead of going over to Bernard's desk, I decided to work on the MacBook Pro instead. I got the trial version of 3D Studio Max installed and played around with it. I feel like I am a graphics designer when working with these modeling tools! It’s a whole new thing to me, and I had to look for tutorials to learn the various different functionalities in the modeling tool. Hence, it is another valuable learning process for me.

I worked with Gim Han as well so as to get the heart mesh from him. He sent me 3 different models that have different vertex sets. I managed to get the vertex animations up fairly quickly. We were using a technique called morphing to come up with the animations.

The problem came just when we thought that the animations were complete. When I tried exporting the model into a .pod file, the animations were missing. Then it came back to me. POD files do not support vertex animations. We had a discussion with Kevin, and decided that we should move on to the other components of our project first. While working on the other components, we would have to read up on other techniques that we could use to come up with the animations.

Hence, on Friday, we watched the podcast lectures to find out more on the UI controls for the iPad, namely the UISplitViewController and the UIPopoverView. I played around with these controls, and we discussed on our actual UI layout for the iPad application. Kevin, Zac and I gave our suggestions as to how the interface should look. My experience gained from working on my Major Project, which is also a medical application, helped quite a bit, since I was the one working on the UI then. We managed to derive at one that would give the best user experience.

I managed to get the UISplitViewController working, but there is still a problem when the interface orientation changes to landscape on the iPad. Somehow, the EAGLView cannot be seen at all, even though it is still there. Then we realized that it has got something to do with the animations when we draw the view. If the animation is stopped before the rotation, we could see the view clearly. However, the moment we turn the animation back on, it disappears from our sight once again.

Spent quite some time debugging, but still could not solve the problem. We would have to work on this next week.

I am glad that in TP, we get mant chances to work with others for our assignments. With this experience, I was able to work better with my colleagues whenever I needed help from them.

26 November 2010

Got my hands on some utilities that we can use to convert .dae files to .pod files. It can be found here:
http://www.imgtec.com/powervr/insider/powervr-collada2pod.asp

Managed to get some sample .dae files to test out the conversion, and this website provides some good models:

http://www.collada.org/owl/

Once I got the conversion done, I got it tested out with PVRShaman. This utility allows me to import the .pod files that I have and view it. I can even do things like rotation, panning, etc. Changing display to wireframe can be done too. So with that, I'm actually able to see that the .dae file is converted to .pod nicely. Here's the utility:
http://www.imgtec.com/powervr/insider/powervr-pvrshaman.asp

Many 3D modeling tools out there are able to export the models into .dae files. Now the question is, am I able to use Blender to export the models into .pod files directly? If that can be done, we can easily skip the step for conversion. Did quite a lot of research, and realized that most people out there do the conversion using this method.

I then looked into the requirements for having animations in .pod files. Did some analysis on the .dae files that I have downloaded, and found out that the animations are actually inside the .pod file itself. After going through some forums, many users are saying that they create animations by capturing the frames. Once they got the animations up, they could just easily export the 3D model into a .dae file, which can then be converted to a .pod file. There, we would then have our animations.