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
three.js and refer to the original repo instead. So please make any form of feature requests at the original repo.
Thank you for the comment. I missed your reply.
I made a just ported version of old threeoctree.
ported version of old threeoctree
Just to be clear, the still has the same problem as the previous version. That is, it uses
Geometry, but it needs to be updated to use
@diem389 Welcome to the community!
@looeee Support for BufferGeometry will be a nice update, but making the old version work on the newest release of three.js is a good step too.
@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
Is BufferGeometry getting renamed to Geometry?
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
I totally agree with this move, it is just logical also since the internal conversion is hidden a lot people still use the old geometry class.
Thanks for your information.
I came searching for a more recent implementation of octree for three.js and here you are. THANK YOU. Did you ever end up implementing BufferGeometry?
Another curious one here!
If you want to use an Octree to speed up raycasting, I suggest you use this alternative instead: