Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Visualising a custom OcTree with octovis #199

Open
heuristicus opened this issue Jan 19, 2018 · 1 comment
Open

Visualising a custom OcTree with octovis #199

heuristicus opened this issue Jan 19, 2018 · 1 comment

Comments

@heuristicus
Copy link

I've created a custom octree type, by taking the ColorOcTree and replacing Color with another word, let's say Custom. For now, this tree has exactly the same code as the colour octree. The custom type is defined outside the octree and octovis packages. I'd like to display the trees I generate with octovis, but I can't just define the type, save the tree, and then open the saved file with octovis, because I get the error ERROR: Could not create octree of type CustomOcTree, not in store in classIDMapping. This is expected, because without the header being included, the StaticMemberInitializer hasn't been called, so the AbstractOcTree::registerTreeType isn't called either.

I've looked around in the issues and haven't found anything about how to visualise custom types. There doesn't appear to be any mechanism for informing octovis about custom types, and so I'm not sure what the best way to do this would be. A naive method which would probably work would be to create a duplicate of the entire viewer, with the custom headers added. That seems inefficient, and I'd be interested in reading some suggestions about how this might be done.

@ahornung
Copy link
Member

Yes, I think currently the only option is a custom implementation as the tree type needs to be known and compiled in. You could derive from the viewer and / or drawing widget and only extend your custom functionality.

What would be needed is some sort of dynamic customization option, which could at run-time pick the correct drawing functionality. This could be done using Qt plugins, and would require a major rewrite of octovis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants