Cold neck Fri, Oct 17. 2008
Bridging the gap Fri, Oct 17. 2008
Ok, first small victories.
The last few days I spent analysing the VisualAp code structure and how everything fits together. The business-logic is different to the one I'll be using, although the basic workings are very very similar. So what I did is trying to find common points and to make the implementation in VisualAp more abstract. I tried to change as few as possible, I should contact the author of visualap. It's open source, so no problem there, but maybe he finds some of my changes usefull.
The basic structure in VisualAp is like this: you got a Bean, a small jar file, which is read and which contains the functions that are offered by this unit. This bean is encapsulated in a BeanDelegate. This beandelegate is stored in an array. The BeanDelegate was split into a Delegate Interface and the usual BeanDelegate for VisualAp and my NodeDelegate for ImageFlow. This is one example.
Another one would be, how to draw the flow-graph. That was much more tricky, because of different dependencies. First, the graph is painted by the GPanel, this accesses the list of BeanDelegates, as well as a list of all Nodes. I had to change a few things in the GPanel, so I can actually access the Node-list, add my own nodes, which extend the same Nodes-Interface as VisualAp. My nodes then get some nice new painting-methods, that I mentioned in the post before. So I create a UnitElement, I add it to a new Node, which has an origin on the panel and this Node draws it's NodeIcon. VisualAp already brings functions to select and move it. Very nice.
Actually, I wanted to post a screenshot, but a screenshot doesn't show anything, except for the things I showed in the last post.
Well anyway …
Next thing will be to extend this. Now it's only one single node, I'll add more and work on the methods to connect them.
May aim is to have a fully working graph asap. This means I have a bunch of nodes, I can connect them and somewhere a run button.
The last few days I spent analysing the VisualAp code structure and how everything fits together. The business-logic is different to the one I'll be using, although the basic workings are very very similar. So what I did is trying to find common points and to make the implementation in VisualAp more abstract. I tried to change as few as possible, I should contact the author of visualap. It's open source, so no problem there, but maybe he finds some of my changes usefull.
The basic structure in VisualAp is like this: you got a Bean, a small jar file, which is read and which contains the functions that are offered by this unit. This bean is encapsulated in a BeanDelegate. This beandelegate is stored in an array. The BeanDelegate was split into a Delegate Interface and the usual BeanDelegate for VisualAp and my NodeDelegate for ImageFlow. This is one example.
Another one would be, how to draw the flow-graph. That was much more tricky, because of different dependencies. First, the graph is painted by the GPanel, this accesses the list of BeanDelegates, as well as a list of all Nodes. I had to change a few things in the GPanel, so I can actually access the Node-list, add my own nodes, which extend the same Nodes-Interface as VisualAp. My nodes then get some nice new painting-methods, that I mentioned in the post before. So I create a UnitElement, I add it to a new Node, which has an origin on the panel and this Node draws it's NodeIcon. VisualAp already brings functions to select and move it. Very nice.
Actually, I wanted to post a screenshot, but a screenshot doesn't show anything, except for the things I showed in the last post.
Well anyway …
First view of the Imageflow application
Next thing will be to extend this. Now it's only one single node, I'll add more and work on the methods to connect them.
May aim is to have a fully working graph asap. This means I have a bunch of nodes, I can connect them and somewhere a run button.
Finding the bridge Wed, Oct 15. 2008
Currently I'm working on two things. The major thing is trying to find the bridge between my flow-logic and the visual drawing-framework of VisualAp. VisualAp already has alot of the functionality I originally wanted, now, since the prototype of Prof Barthel, on which I'm developing goes technically in a different direction, I have to find where both conceptions can be combined. VisualAp bases it's Units on Java-Beans, small Jar-files, that capsulate the complete functionality for one unit. This is not good for us and now I have to see how to work around the bean-logic to hook our Classes into it. Fortunately VisualAp is Open Source and I can do changes, altough I try to avoid it. I could imagine preparing a patch which includes some of my refactorings to make it of bigger common use.
My second work is bit more fun. If I get bored on the one thing, I can switch to this one: designing the unit icons. Of course depending on how I do the implementation of the VisualAp-bridge, the icons may change, but still it's fun trying things with Java2D.
My second work is bit more fun. If I get bored on the one thing, I can switch to this one: designing the unit icons. Of course depending on how I do the implementation of the VisualAp-bridge, the icons may change, but still it's fun trying things with Java2D.
WIP, Barthel's draft and my adaption
Motivation Sat, Oct 11. 2008
Maybe let's start with some background story like how did I find my topic.
During our 3rd semester we had a videoproject in which I did all effects shots. I used a software called "Digital Fusion", which was just fun to work with. The reason is simple. It's node-based. In contrast to other video effects software like After Effects, Fusion didn't use a simple layer-principle for composition. Usually you have one layer with an image or an video and you add filters, which are applied and in worst case like in photoshop even merged, so you can't change them later on. In Fusion, you got your nodes, with special functions and filters, you add them to a workspace and connect them to a large graph, which represents the actions you want to ppply on this video.
As I said this way of creating an environment, where I set up my composition completely without harmfull graphic manipulation to my images/video impressed me. Since then I hate Photoshop for not having this kind of workflow, although it has some aspects. Even worse with Gimp, it's just not the same.
So my friend David got me the idea, hey why not write your Bachelor thesis about it. I loved it. This was 2 years ago. In January I approached my Professor and he was keen on the idea as well. We sat together and made a plan, to make this idea a proper thesis and an interesting project. About this I will talk in an nother post.
During our 3rd semester we had a videoproject in which I did all effects shots. I used a software called "Digital Fusion", which was just fun to work with. The reason is simple. It's node-based. In contrast to other video effects software like After Effects, Fusion didn't use a simple layer-principle for composition. Usually you have one layer with an image or an video and you add filters, which are applied and in worst case like in photoshop even merged, so you can't change them later on. In Fusion, you got your nodes, with special functions and filters, you add them to a workspace and connect them to a large graph, which represents the actions you want to ppply on this video.
As I said this way of creating an environment, where I set up my composition completely without harmfull graphic manipulation to my images/video impressed me. Since then I hate Photoshop for not having this kind of workflow, although it has some aspects. Even worse with Gimp, it's just not the same.
So my friend David got me the idea, hey why not write your Bachelor thesis about it. I loved it. This was 2 years ago. In January I approached my Professor and he was keen on the idea as well. We sat together and made a plan, to make this idea a proper thesis and an interesting project. About this I will talk in an nother post.
Introduction to the blog Sat, Oct 11. 2008
It's the beginning of october, I have the topic for my Bachelor thesis and since it's somethin quite useful and interesting in development, I see to blog about it every now and then. Hope fully showing some nice progress and the current state of the project. Explaining how it works and what to make of it in the end.
I guess my first posts should be about what is planed here. We'll let's see.
I guess my first posts should be about what is planed here. We'll let's see.
