Related to #415 (comment)
When raycasting against the tileset two paths are taken - one that smartly traverses the tileset based on parent bounds and the internal three.js logic one that iterates over all tileset children that have an "empty" raycast function assigned. The latter set of tile iterations can take a significant amount of time.
When the mouse is not over the tileset it can take 0ms while the individual tile iterations can take significantly longer (0.5-1ms). And when hovering over a tile the tile iteratation can take over half the iteration time. Sometimes significantly more than half due to this three.js overhead. Some method providing more control over the raycast logic would help alleviate this.
Related to #415 (comment)
When raycasting against the tileset two paths are taken - one that smartly traverses the tileset based on parent bounds and the internal three.js logic one that iterates over all tileset children that have an "empty" raycast function assigned. The latter set of tile iterations can take a significant amount of time.
When the mouse is not over the tileset it can take 0ms while the individual tile iterations can take significantly longer (0.5-1ms). And when hovering over a tile the tile iteratation can take over half the iteration time. Sometimes significantly more than half due to this three.js overhead. Some method providing more control over the raycast logic would help alleviate this.