GLTF Converter Features Roadmap & Requests

[unitycoder]

• Easier installation (installer or include converter in the customer download zip)
• Preview option (before full conversion, could preview if scale is correct, or if split to grid is good size etc)
• Email notifications for plugin updates (add mailing list)
• Filtering (cleanup dense areas with neighbor point distance based filter) point distance based filter #47
• Add setting for min/max points per tile (then filter out excess points) Add setting for min/max points per tile (then filter out excess points) #49
• some place to post gltf plugin update news/release notes
• ...

You can comment this topic and request other features

[Katastroowl]

Sometimes the Results of GLB seem to produce '-1.70e+38' values or set e.g. a center of a segment to '[-4.25e+37, -4.25e+37, -4.25e+37]'. Currently we have to write out own Cleaning Algorithm, that fixes that. Maybe during the generation this can be resolved?
At first sight, it does not seem to be much of a loss of data, but something is going on here.

[Katastroowl]

It would be cool, when selecting the Split To Grid Option, that we can also set an average bracket or some sort of min/max density for the Segment. This can not be resolved by using the existing Options like Remove/ Keep points, since point clouds are often not evenly distributed, while there are way more points where exact scanning took palce and less points at further distanciated corners of the object(s). With such an option, we could make the Splitting more evenly. Currently, on our example, we receive Segments that are 400KB in size but also 700MB, for the same Grid: 5m. A potential algorithm can be to remove points, that do not add significant detail, because their neighbors would not differ in space position (3d position) too much, to give an example.

[unitycoder]

It would be cool, when selecting the Split To Grid Option, that we can also set an average bracket or some sort of min/max density for the Segment. This can not be resolved by using the existing Options like Remove/ Keep points, since point clouds are often not evenly distributed,

So would it work in your case if it basically subdivides world to grid and keeps single point within each grid cell?
(so it clears out those dense areas)

[Katastroowl]

As I can percept it now, it looks like the Segmentation (Split to Grid) does cubes, so we can start the argumentation on that. Good, now each Cube have n points. n can vary from a few points up to many points.
If there is an option, to set minimum points amount per Grid and maximum points amount per Grid, people would be able to even the outcome regarding the size of each Grid junk (glb file size).
Ideally the position in world space, of course, should not be affected and kept in tact - But if that is for others not so important, that would be another feature to deactivate this. So when taking all the junks (glb files) and placing them at the same position, the original object should be reconstructed, as points, but still visible.
Finally, thanks to min/max settings, each junk would have similar size and that could streamline loding on demand or other workflows etc. - If the setting is not activated, it divides as normally.
Important for the users also might be, that if the min amount cannot be reached, the grid still is processed, but could write a warning in the log (in case e.g. when using the json log for the command line workflow). The max amount always can be kept, basically, but users will suffer more or less with quality and loss of detail, even here it would be possible to log when a significant loss would happen regarding detail quality.

That are just a few advanced ideas/ 2 cents, that are relatively easy to implement and have some value.