Realize that “brackets” result in a new object being created every time you call that constructor function, thus it’s extra garbage for you garbage collector which will come to collect and cause an FPS hickup at some point down the line. Not using “brackets” for potentially performance critical parts of the library and for that matter any code you write is just smart choice. Nothing to do with syntax preference here.
Hope that helps. Also, documentation should be your first place to check, then the source code on github and debugger. Sadly we’re not at the point where you can write “drAw pReTtY piCtUrE pLx” and see the library produce expected result.
That said, a lot of the points in this discussion seem to go off-track. If you want cheap ray-casting, you should probably invest into a spatial index, this would simplify your user-side code significantly. Trying to mess with sphere here, or breaking your models into 1000 pieces manually is equivalent of using a text file instead of a database, reading it line-by-line instead of using any of the numerous SQL and other types of databases on the market. You’re just inviting bugs and headache, and in the end your solution is probably going to be inferior in terms of performance too.
I have advocated for having spatial index inside three.js in the past, at this point I don’t really care, since there are clear drawbacks to doing that as well as obvious benefits. In my engine I use spatial indices extensively and the projects I work on would be frankly impossible without that.
On the subject of bounding spheres, I would note that bounding spheres in three.js are severely overestimated, bounding sphere is computed from bounding box, which guarantees that the sphere will be an overestimation except the case where your geometry is literally an axis-aligned box. I use an alternative mechanism for computing bounding spheres that results in spheres with roughly 50% or smaller volume compared to those created with three.js.