I have some questions on how to accomplish some tasks from a CC plugin.
My plugin creates a new toolbar with a set of functions taken from PCL (PointCloudLibrary).
So, questions:
1. Some of the functions simply add a scalar field (or colors or normals). How can I then update the Properties view? I can have access to public methods of MainWindow but i cannot find a method actually working for this task. MainWindow::update() and MainWindow::UpdateUI() does not seem to work. Also main_window->propertiesTreeView->update() does not work.
2. Sometimes I need to let the user to start the filter on a given selected entity, but next i need to let the user chose other entities, from a combobox for example. How can I get the list of all the entities present in dbRoot (I guess) for a given type (i.e. CC_POINT_CLOUD)? Is there any convenient way?
3. I think I will need to add new types to CC. For example PCL permits the computation of several features descriptor, so it will be useful to create a new type, something like "PCL_FEATURE_DESCRIPTOR" to being able to show this data inside the tree view, as a cloud's child, and so on ... Is this possible without the need to change internal CC code? The same for Keypoints etc...
4. On slowness of point picking tool. I see that is pretty slow on big clouds. I had a look at implementation and I see is based on some OpenGL functionality, isn't? I don't know anythink on how OpenGl performs this but i think it would be faster to implement a method based on octree and box/ray technique.
http://www.opengl.org/resources/faq/tec ... ection.htm gives some interesting hints
http://jgt.akpeters.com/papers/WilliamsEtAl05/ this paper describe an efficient implementation of the ray/box intersection algorithm.
is this feasible? Could this improve the velocity in point picking? I really need a fast picking tool for my work, so I could try to implement this if it is a good solutions, but i will need some information on how to work with cc implementation of octree etc..
Thanks a lot
Luca
On accessibility of CC by plugins, and other questions
Re: On accessibility of CC by plugins, and other questions
first problem solved :-) actually UpdateUI() do the trick, sorry...
Re: On accessibility of CC by plugins, and other questions
Hello Luca,
1. For standard plugins, there's a 'uiModificationFlags' as output variable (second parameter of 'doAction').
You can set the 'CC_PLUGIN_REFRESH_ENTITY_BROWSER' bit flag to make CC do what you want on plugin completion.
Look to qPoissonRecon for an example.
2. Indeed, we could modify the default plugin mechanism and set the 'dbRoot' as standard input of 'doAction'. In this case, we should also add a flag (still using uiModificationFlags) to warn CC that other entities may have been modified.
3. This is not really the spirit of a plugin, and this kind of contamination by PCL will be troublesome.We could have a "blob" structure, like QVariant, to let a plugin add a custom dataset. It will be associated with a custom ID and name (just as Qt custom events for example). CC will handle them as other entities children but that's all. This way your plugin will be able to store data and read it back through different calls. I'll try to add this kind of object asap (you may provide me with a concrete example?)
4. Point picking with OpenGL is generally considered as a fast and simple mechanism. However, in the standard mode that we use here, one has to display the entire entity in order to guess what point is picked (this explains why it's slower on big datasets). The issue with the ray/box intersection algorithms (or any other algorithm) is that you need a structure (such as an octree) and computing this structure takes also a certain amount of time (so this is a trade-off between either a few 'slow' picks and no pre-computation, or a lot of 'fast' picks and pre-computation). It would be possible of course to let the user choose what mode he prefers. If you want to try to develop such a method, you're welcome. But you're right, you'll need a good knowledge of the DgmOctree (and I'm not sure streamed octrees are best suited for this kind of algorithm). You can also had a more standard octree to CC (there's already bits of code for this, hidden in the DgmOctree class).
Have a good day,
Daniel
1. For standard plugins, there's a 'uiModificationFlags' as output variable (second parameter of 'doAction').
You can set the 'CC_PLUGIN_REFRESH_ENTITY_BROWSER' bit flag to make CC do what you want on plugin completion.
Code: Select all
uiModificationFlags |= CC_PLUGIN_REFRESH_ENTITY_BROWSER;
2. Indeed, we could modify the default plugin mechanism and set the 'dbRoot' as standard input of 'doAction'. In this case, we should also add a flag (still using uiModificationFlags) to warn CC that other entities may have been modified.
3. This is not really the spirit of a plugin, and this kind of contamination by PCL will be troublesome.We could have a "blob" structure, like QVariant, to let a plugin add a custom dataset. It will be associated with a custom ID and name (just as Qt custom events for example). CC will handle them as other entities children but that's all. This way your plugin will be able to store data and read it back through different calls. I'll try to add this kind of object asap (you may provide me with a concrete example?)
4. Point picking with OpenGL is generally considered as a fast and simple mechanism. However, in the standard mode that we use here, one has to display the entire entity in order to guess what point is picked (this explains why it's slower on big datasets). The issue with the ray/box intersection algorithms (or any other algorithm) is that you need a structure (such as an octree) and computing this structure takes also a certain amount of time (so this is a trade-off between either a few 'slow' picks and no pre-computation, or a lot of 'fast' picks and pre-computation). It would be possible of course to let the user choose what mode he prefers. If you want to try to develop such a method, you're welcome. But you're right, you'll need a good knowledge of the DgmOctree (and I'm not sure streamed octrees are best suited for this kind of algorithm). You can also had a more standard octree to CC (there's already bits of code for this, hidden in the DgmOctree class).
Have a good day,
Daniel