Hi, I want to try to use Octree raycasting in my application.
I found the threeoctree package that implements Octree in THREE, but it only supports up to r60. The author of the package did include a link to a version last year that is supposedly compatible with “latest” THREE, so I went to the link, but the link is unavailable. It seems like it was once part of the examples/js directory, but was taken down for some reason. That being said, I could not find any example usage of Octree in THREE that were occasionally mentioned across forums/stackoverflow/etc.
Have these examples been moved somewhere else, or are they taken down because they no longer works with the latest THREE?
I have made a PR at the original repo in order to avoid such confusion. But the owner of Octree seems to ignore it
No, they were deleted with this PR. Octree uses an old geometry format that is going to be removed from the library. Since the implementation is complex and a migration to BufferGeometry time-consuming, we decided to remove Octree from three.js and refer to the original repo instead. So please make any form of feature requests at the original repo.
@EliasHasle I think there’s a lot wrong if you’re using a spatial index for your geometry and don’t use a BufferGeometry. But that’s just my take, I think most people don’t need it, and those who need this octree - probably want something more advanced anyway.
As far as I see it - it’s a learning tool, and for learning - it’s best to learn the right way from the start. The right way to use three.js is to use BufferGeometry, since that’s the main path forward currently and all of the documentation points in that direction generally.
Conversion between buffergeometry and geometry is a very easy step. If I have some time after closing some urgent work, I could make it support buffergeometry. I hope.
The idea is to avoid any dependency to THREE.Geometry since the class will be removed at some point (at least it will be renamed to THREE.LegacyGeometry). So you have to develop the code from scratch based on BufferGeometry.
Maybe. I mean it would be the ideal case however the impact of this change might be too radical. I think we first want to see the community’s reaction when WebGLRenderer stops rendering Geometry