New Visualization Engine

[admin]

This is the thread for asking more details about the New Visualization Engine proposal.

[apatriarca]

I plan to write a blog article about the current status of the visualization engine, but I think I should probably give some information here.

The main goal of last year GSoC project was to design a new modular visualization engine using a modern graphics pipeline and able to support as much systems as possible. During the summer I implemented a toy application visualizing a graph using different pipelines based on different OpenGL versions. Each pipeline was implemented in a different renderer object and they can be easily changed at runtime. I was mainly interested in the implementation of the renderers, but I also redesigned the entire engine to better separate the visualization from the graph update and event handling. That was mainly motivated by some problems with the current architecture. It currently use a model-view-controller architecture, where the model and the view components run in a different thread and communicate using events. This design was the result of several bad designs and some problems with the new version of JOGL (jogamp is now a lot better). After that I had to pause the development of the visualization engine and I restarted working on it only recently.

In the last weeks I implemented a temporary API to communicate with the rest of the system (it do nothing) and implemented some of the ideas of last year project in Gephi. The basic architecture is in place and I can use OpenGL commands to display things on the screen. The next step is to implement the renderers from last year project. Some things will be implemented differently thought. In particular, implementing the different pipelines, I noted there was a lot of common code which I wasn't able to eliminate using the old design. I have therefore decided to define the pipelines as the composition of different steps (which is actually what a pipeline really is) and maybe make it completely data-driven (http://bitsquid.blogspot.com/2011/03/bi ... riven.html).

Since the new architecture is completely different than the old one, the visualization API should be completely rewritten. In particular, since the model and the view components update at a fixed framerate, all the events are in my idea handled asynchronously. This may cause some problems with the current API. The new engine also completely lacks user interaction functionalities and a more efficient spatial data structure should be implemented to speed up selection and visibility queries. I will continue to work on the visualization engine in the following month and during the summer (even if not full time), so this is a collaborative project. I have quite a lot of experience with the visualization part, so I think the proposal should mainly focus on the interaction with the user and the design of the visualization API. You can also give suggestions and do some work on the visualization part if you are interested though.

[vojtech_b]

Hello,

I would like to know more about the new visualization API. What are the main reasons for not being able to use the old event architecture in new API?

Also it seems to me that Gephi currently uses Octrees as a spatial data structure. What's wrong with this? Is it too slow or difficult to operate?

Lastly are there any parts of the old API that could be reused such as the StandardGraphIO or StandardVizEventManager classes?

Thanks
Vojtech

[mbastian]

I can answer, but Antonio may have better insights

I would like to know more about the new visualization API. What are the main reasons for not being able to use the old event architecture in new API?

The event system is pretty good, I think we can reuse it, but it needs to be properly exposed in the VisualizationAPI. Currently it's only in the VisualizationModule.

Also it seems to me that Gephi currently uses Octrees as a spatial data structure. What's wrong with this? Is it too slow or difficult to operate?

Yes, we use an Octree and it does its job with good performances. If its compatible with the new architecture, I think we can simply reuse it in the first place and maybe improve it later if we have time. Antonio?

Lastly are there any parts of the old API that could be reused such as the StandardGraphIO or StandardVizEventManager classes?

We can certainly reuse some of this code for the new engine. It's great you are looking at the legacy code, that will help a lot while working on the new engine.

[apatriarca]

I would like to know more about the new visualization API. What are the main reasons for not being able to use the old event architecture in new API?

The old visualization engine exposed too much to the other parts of Gephi. Therefore, when I deleted the old module to make the new one, I also had to change the Visualization API. The current API is quite similar to the old one, but the engine architecture is not and it may be hard to reuse old code. Finally, in my design, which can be changed if a better design is found, the graph data structure is updated at a fixed frame rate. This means a function to get the selected nodes either returns the old selected nodes or it should wait the next update.

Also it seems to me that Gephi currently uses Octrees as a spatial data structure. What's wrong with this? Is it too slow or difficult to operate?

Nothing wrong. The code of the new engine is completely different from the old one and it's difficult to reuse the old octree implementation. Moreover, the old engine use the Picking API to implement selection. The new engine shouldn't use it, picking should be implemented tracing rays or calculating intersections with frustums or cones. This is because those parts of OpenGL has been dropped in newer OpenGL versions. I think it's easier to implement a new spatial data structure than reuse the old code, but you can implement an octree and the performance should be quite good.

Lastly are there any parts of the old API that could be reused such as the StandardGraphIO or StandardVizEventManager classes?

I don't know. You can surely take inspiration and copy some code fragments from the old code, but I think it may be hard to copy entire classes. It really depends on how much those classes depends on the legacy visualization engine architecture.

[vojtech_b]

Also it seems to me that Gephi currently uses Octrees as a spatial data structure. What's wrong with this? Is it too slow or difficult to operate?

Nothing wrong. The code of the new engine is completely different from the old one and it's difficult to reuse the old octree implementation. Moreover, the old engine use the Picking API to implement selection. The new engine shouldn't use it, picking should be implemented tracing rays or calculating intersections with frustums or cones. This is because those parts of OpenGL has been dropped in newer OpenGL versions. I think it's easier to implement a new spatial data structure than reuse the old code, but you can implement an octree and the performance should be quite good.

Have you thought about not using the OpenGL selection buffer, but instead have a proper Octree structure that stores information about graph nodes in respective octants and not the other way round? Did you do the selection to take the load away from CPU? I think that computing rectangle intersections (or other if there is a need for more complex selection tool than rectangle) could be even faster. Also there are other structures such as R-trees that can be faster on average, but I understand that the graph can be changing its structure a lot, so this would be a special case, but still it could be worth trying. What do you think?

[apatriarca]

Have you thought about not using the OpenGL selection buffer, but instead have a proper Octree structure that stores information about graph nodes in respective octants and not the other way round? Did you do the selection to take the load away from CPU? I think that computing rectangle intersections (or other if there is a need for more complex selection tool than rectangle) could be even faster. Also there are other structures such as R-trees that can be faster on average, but I understand that the graph can be changing its structure a lot, so this would be a special case, but still it could be worth trying. What do you think?

I'm not using the selection buffer. This is how the old visualization engine works and the new one won't use it since it's deprecated. Selection should be implemented directly computing the intersections between the nodes/bounding boxes and the frustum/rectangle/cone (the exact shape depends on the projection used and selection area shape since we are working in 3D). In my last year proposal I actually suggested to use a BVH since several articles in the ray tracing community suggested them for dynamic scenes.

[apatriarca]

Hi Vojtech,

I read your proposal and I have some comments:

• Describe the project idea using your own words. Don't copy it from the idea page.
• In the new branch the old code has been deleted. The old classes and interfaces do not exists anymore. VizEventManager, GraphIO and GraphDrawable are not part of the new implementation. In the current design the Viewer receives the events from JOGL (it's a GLEventListener) and all the other events pass through the Controller class. It isn't very clear how the new classes and interfaces will relate to the new engine current design.
• You have to consider the radius when computing intersection between the selection shape and the nodes. The new engine will also support different shapes such as square, triangle, pentagon...
• How the new engine will communicate with the rest of Gephi? This is an important part of this project.

I would like to discuss the proposal and the current engine design using a more immediate media (MSN, Google Talk, Skype..).

[hassan1990]

Hello everyone,

My name is Hassan Muhammad. I am a Computer Engineering student and I am applying for the Gephi project.

I realized that you have redesigned the whole architecture of the program and that in the old architecture, the visualization engine and the visualization API were not really separated from each other. so when you changed the visualization engine last year, the visualization API had to be changed accordingly.

I have read the previous posts in this topic and the official proposals at the wiki. I have some questions in my mind that need to be answered before I can finish my proposal:
- Do I have to make a detailed design in my proposal? or just a high-level design of how things should interact between each other? keeping in mind that in order to make a detailed design I will have to read major parts of the code which will exceed the GSoC deadline.
- In this year, all that is required is just to create the new visualization API, integrate the visualization engine with Gephi and some context menu actions. no UI will be changed?

best regards,

Hassan

[apatriarca]

- Do I have to make a detailed design in my proposal? or just a high-level design of how things should interact between each other? keeping in mind that in order to make a detailed design I will have to read major parts of the code which will exceed the GSoC deadline.

You should make your proposal as detailed as possible. Keep in mind that there is already an other proposal to this idea and you should try to make the better proposal. This means you should look motivated and able to complete the project.

- In this year, all that is required is just to create the new visualization API, integrate the visualization engine with Gephi and some context menu actions. no UI will be changed?

I think there is already a lot of things to do with that. But you can also include UI changes if you like.

If you are truly interested in this project, I want to chat with you about your ideas and the current architecture. Send me a PM.