Pointcloud viewer library

[mineichen]

Sorry for spamming your issues. I'm very impressed with your pointcloud viewer and like to use it in my project. At the moment, the renderer has some dependencies to your project named "project" which make it less ideal for a library someone uses in their own code. If you agree to remove this dependency, I'd be happy to fork this project and work on the separation. If you have other plans and think, that you need the renderer to be tied to your project, I'll use your code to build a viewer one might want to use for their own application and give you credits in the readme. I'd also use a popular alternative like nalgebra or glam instead of math to make it easier to integrate. What are your preferences?

[antonWetzel]

the project crate

• content
  • (I) project, node and point definitions
  • (II) datafile definitions
• the name project is the name I use for the pointcloud with lods, segmentation and additional properties, not the treee repository as a software project
• this is in a seperate crate, because the importer and viewer both need these definitions
• any other importer could create a project based on the definitions and the viewer could display the result

the viewer (+ render) crate

• content
  • (A) camera, level of detail and tree
  • (B) data loading
  • (C) main loop
  • (D) window, rendering and user interface
• everything is here without a real seperation

(easy/possible) options for viewer as a library

• library contains only (A)
  • library consumer implements rendering backend, data loading user interface and main loop
• library contains (A) and (D)
  • consumer can just change the data source, the library creates a window with the viewer
  • consumer main loop updates the window and provides the data to render
• library contains all
  • consumer just changes the importer

why custom math library

• I wanted to try constant generics
• maybe I change everything to nalgebra

conclusion

• if one of the options matches your wanted use case I can change the viewer
• if not do whatever you want with the source

[mineichen]

Happy to hear that you are open for the idea. I like your separation of renderer and "AllInOne" viewer so people can decide if they want to ship their own windowing. I just think, that your PointCloud format and loaders shouldn't be in the core. It should be an extension similar to loader for laz/e57... I'll ned my own custom format for Pointclouds from Polar-Coordinates. So I'll go "for library contains (A) and (D) " but maybe separate the viewer from your project-specific egui parts.

I've seen, that the "project"-project is quite small and has few dependencies, but still contains definitions for Project-Files which imho don't belong into such a library. I currently don't know how easy it is to separate the windowing from your e-gui code, which contains buttons for loading projects, but I'll give it a try. At the end you can decide if you want to merge the pull request or simply ignore it... I'd go the migrate slowly path anyways, as rust doesn't provide a good user experience for huge refactoring-steps. I'll keep your Math-Library as is for the moment. If you want to merge, this could be done separately and if not, I'll separate it just for the viewer/renderer, not your entire Application. I'll keep you updated in this issue if there is progress

[antonWetzel]

The https://github.com/antonWetzel/treee/tree/nalgebra branch contains the current master with nalgebra instead of custom math if you prefer.

[mineichen]

I worked on it for some hours today. Unfortunately, I've just seen your comment, but i hope that this will not result in big merge hassles, as i touched 23 different files.

I was abe to split the viewer into two parts... The Application-Specific code resides in the viewer-project... The Code which could be shared with other application lives in the newly created "window"-project. I tried to change nothing in the logic, just pure refactoring. The viewer works like before and doesn't have any problems I am aware of. The e57-example in the new "window"-project doesn't work yet though, as it only renders the blue background yet.

The refactoring is not done yet. There are still some simplifications but I think it is big enough already and you should be able to see if it's going into a direction which you want to integrate or not. Please let me know what you want to change or feel free to merge and change as you see fit.

Thank you again for sharing your work

[antonWetzel]

I am still unsure of your ideal final state of window for your usecase.

My guess what you want or don't want to use in your application based on window

• [x] rendering backend
• [x] window creation
• [ ] ui
• [x] camera controller
• [x] level of detail controller
• [ ] import pipeline
• [x] tree structure (but with other data per node/leaf/branch)
• [ ] file logic / data loading

My guess is you got a data source with all the required data (positions, normals, size and properties seperated in leaf and lod nodes) and want to render the data.

[antonWetzel]

See https://github.com/antonWetzel/treee/pull/4 for context.

I don't like the extra window abstraction layer between the final aplication and the render backend

• I think this maybe works better
• 
• render does not change
• tree-logic manages trees, camera and lod
• viewer combines both and adds data loading and ui
• another viewer can reuse render and tree-logic

Does this work for you?

[mineichen]

I aggree, that game might be too broad for all usecases, but if I see how long the refactored "game.rs" became i definitely don't want to have all that boilerplate if I just want to display a simple Pointcloud somewhere. This could however live inside it's own Repository. I also dont like the fact that an external Library has control over the Window. You can't embed it into a larger application this way. Maybe there could be a struct like World(&'mut Window, &'mut Game) which implements the necessary traits or have a more functional approach. I don't really know how i would build it yet...

Maybe it's too early to have common Code for the Viewer and just copying the Viewer is the best solution. Tree, Camera and LOD is not enough code to justify another repository and limiting design decisions around it... If either of us ends up with a generic solution, it would be great to notify each other. Thank you very much for your time and for sharing your code. We'll hopefully hear from each other.

[antonWetzel]

The current development for this project is in branch https://github.com/antonWetzel/treee/tree/treee2.

This combines the import and viewer into one tightly coupled program. At the same time many functions for the rendering of large point clouds are lost.

For a general purpose point cloud viewer, the best option is to fork the current main branch and separate the input data code. Because my focus is not on a general purpose point cloud viewer, I am closing this issue.