New Visualization Engine
Posted: 19 Mar 2011 18:09
This is the thread for asking more details about the New Visualization Engine proposal.
Please post new questions on facebook group too (https://www.facebook.com/groups/gephi)
https://forum-gephi.org/
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.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?
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?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?
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.Lastly are there any parts of the old API that could be reused such as the StandardGraphIO or StandardVizEventManager classes?
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.vojtech_b wrote: 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?
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.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?
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.Lastly are there any parts of the old API that could be reused such as the StandardGraphIO or StandardVizEventManager classes?
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?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.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?
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.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?
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.hassan1990 wrote: - 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.
I think there is already a lot of things to do with that. But you can also include UI changes if you like.hassan1990 wrote: - 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?