Raycaster performance drops dramatically

[visus100]

Raycaster performance dropdown dramatically in realise 103 but in previous lower works great (checked r102, r99, r98).

There is also strange dependence if mouse hovering on Lee perry mesh fps drops down between 20-30, but if hover mesh and click left mouse button to change camera view (orbit controlls) performance stabile 60fps with raycasting.

I also noticed that when i close chrome console i get 15 fps more, so maybe its not much dramatically but it's not good.

• codepen

Three.js version

• Dev
• r103
• ...

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

[Usnul]

I get 60 FPS on your example. There has been a lot of discussion on Raycast performance, I have advocated heavily for a spatial index, which enables logarithmic complexity of raycasting, versus the current linear. Here's an example, assuming a single operation takes 100 nanoseconds, cast times:

method	polycount	time
spatial index	100	460ns
current	100	10000ns
spatial index	10,000	920ns
current	10,000	1000000ns (1ms)
spatial index	1,000,000	1381ns
current	1,000,000	10000000ns (100ms)

If performance of Raycaster is important for you - I recommend using an external solution with a spatial index.

EDIT:

There used to be an implementation of Octree in three.js, but it was removed. Here's the relevant commit:
7aa204e
You can revert that locally to recover the code if you need it.

My own implementation is closed source, if you really want it - we can talk about the licensing, but you'd probably be served well enough by a plethora of JS spatial index implementations here on github that are totally free.

Here are some of my older posts on the subject, reading through might yield some useful information for you:
#13909
#13807
#5571
#12857

[arpu]

@Usnul do you know any implementation of raycaster with spatial index for THREE,js?

[visus100]

@Usnul What computer specyfication did u test it? Are u try to open console? Are u made the example full screen (for more render space because with smaller render space i also reach 60FPS)?

I tried this on my laptop spec:
GTX 960m
Intel i7 2.6 GHz
16GB RAM

Above comparing test performance images with R103 vs R102

Please compare with 102
<script src="https://cdnjs.cloudflare.com/ajax/libs/three.js/102/three.min.js"></script>

[Usnul]

@visus100

my specs are:
GTX 1080
i7 4.2GHz
16G Ram (dual channel, 2.6Ghz)

The performance bottleneck is CPU+RAM, mostly the CPU i reckon, having a beefy cache on the CPU helps too.

I did have console open - yes.

@arpu
I have edited my answer. Hope that helps.

[visus100]

@Usnul

You have around 2x or even 3x faster PC Spec then i tested this example (It could be reason u gain 60FPS). So i think we should wait till someone will check this with older pc like mine.

Benchmark comparing Graphic cards

[Mugen87]

I'm unable to reproduce the issue with your codepen. Performance is stable at 60 FPS. Tested with an 4 GHz Intel Core i7.

BTW: The GPU is not relevant in this issue. Raycasting happens on the CPU.

[titansoftime]

Hmm. getting a solid 60fps on my work pc (Intel Core i3-3240 and a 12 year old cheap video card).

[visus100]

@titansoftime

Did u also tried to check with open console? Because probably it needs more overload to get sight...
And for now i can't check this on other PC's.

However if +1 will get solid 60fps maybe it's something wrong on my side... Then suggest to close...

[Mugen87]

Yes, I've tested with opened dev tools.

[visus100]

Ok now i know what is new in r103. Raycaster works on morph targets (in r102 and lower not working after morphTargetInfluences. it's pointing on starting geometry) so math was changed too (that could explain hardware requirements), but still i don't understand why i have this situation: "but if hover mesh and click left mouse button to change camera view (orbit controlls) performance stabile 60fps with raycasting."

[Mugen87]

Closing, this for now since it seems the issue is specific to your machine. If you can actually proof a bug in the three.js library, you can reopen the issue. For now, please use the forum or stackoverflow for more feedback.

[mrdoob]

@Usnul Wouldn't be opposed if someone wants to bring back the Octree example. It just seemed that no one was willing to maintain it (reimplement it using BufferGeometry).

[takahirox]

I'm glad, too. projectObject() in renderer seems one of the cpu hot spot functions because frustum culling is slow. I hope Octree can speed it up.

[Usnul]

@Usnul Wouldn't be opposed if someone wants to bring back the Octree example. It just seemed that no one was willing to maintain it (reimplement it using BufferGeometry).

Personally, I do not prefer Octree as a general-purpose solution, I lean more towards BVH, and that's what I use primarily myself too.

My mention of the Octree was not meant as a criticism of it going away. I don't mind very much, in fact - I think it's probably a good thing, as it's a fairly major feature and tacking it on the side is very misleading for a lot of people, I think.

In the past, I did advocate for introducing a spatial index (for example Octree) into the core of rendering system for various reasons (see related issues for full discussion), but there is not enough interest to see that become a part of three.js proper, so from my perspective - the discussion is well resolved on this topic: no spatial index in three.js for now.

Current state of things is fine for me, I hope this clarifies my position a bit more. Again - I'm just providing information, not really pushing for anything here :)

[mrdoob]

Personally, I do not prefer Octree as a general-purpose solution, I lean more towards BVH, and that's what I use primarily myself too.

What about introducing an example using BVH then? :)

[arpu]

i think https://github.com/gkjohnson/three-mesh-bvh could be used for an example

[Usnul]

@mrdoob
Maybe. The code that I do have is a pretty serious spatial index system that I have been working on for several years now, and it would be too big for an "example" I feel, too many parts.

@arpu
yeah, that's a nice example