Possible performance issues for model picking

[javagl]

Possible performance issues for model picking

[javagl]

I moved the intersection test to #11816

The changes for the picking test performance: The main reason for going down the rabbit holes in the last few comments was that I'd like to test it more thoroughly. The pickModel.js uses some some deeply internal/undocumented things. Most of that should not affect the result (the actual change should be largely independent of that). But a few more tests and cleanups will be necessary. I'll open a PR ASAP.

[ggetz]

Thanks for diving into this @javagl!

For the pick ray, we usually use scene.camera.getPickRay.

      const ray = scene.camera.getPickRay(
        new Cartesian2(
          scene.drawingBufferWidth / 2.0,
          scene.drawingBufferHeight / 2.0
        )
      );

If the unit sphere is at the origin, it will intersect the backface correct? Those are ignore unless the options for backface rendering are enabled.

[javagl]

@ggetz I'm currently assuming that it does not matter how the ray is set up. I don't care about the size of the drawing buffer, or whether anything is drawn at all. (It isn't. At least, not according to the "debug canvas". Why? I don't know...).

The sphere is at the origin. A ray that starts at (0,0,10) and goes along (0,0,-1) should intersect it.

(When using the zoomTo+getPickRay approach, nobody knows what the picking ray will be. That sounds problematic when trying to debug something. And ... it was problematic when I tried it. I debugstepped through that a dozen tiimes. I narrowed the test case down to a single quad (two triangles), desperately trying to find an intersection. And in some configurations, it does find an intersection, but only in cases where it shouldn't find one, and ... for the sphere, it does not find one at all).

The sphere itself is at the origin and has a radius of 1. A ray with origin (0.0, 0.0, 10.0) and direction (0,0,-1) should intersect it. I tried many other origins and directions, even one where the ray starts in the sphere and backface culling was disabled. No configuration ever resulted in an intersection with the sphere. (The frustrating thing is: All existing tests that use the Box... glTF models do find intersections. But the sphere seems to be unintersectable...)

[javagl]

All this might be related to enablePick. Or maybe not. I'm looking into it...

EDIT: Just to confirm: It is not possible to load a model that is not rendered (e.g. in a pure NodeJS snippet) - is that correct?

• The Model requires a FrameState (passed to its update) to become ready
• The FrameState requires a Context
• The Context requires a Canvas
• The Canvas must be capable of WebGL

I tried to create something along the lines of

const model = nowJustLoadThat("example.glb");
doSomethingWith(model);

but it seems like it will be necessary to go through that npm run test/fit path, which is quite an impediment for quick tests and debugging...

[ggetz]

It is not possible to load a model that is not rendered (e.g. in a pure NodeJS snippet) - is that correct?

With the current model approach, that is correct.

[javagl]

@ggetz This fell out of my attempt to ... check this performance thing.

But unless you disagree, I'd move the following into a new issue:

(EDIT: This has been moved to #11816 )

---

A quick test more specifically for the performance issue:

I used he development/3D Tiles Picking sandcastle, selected the "Bentlay BIM Model", and clicked around in that.

(It also does not return a pick result at places where it should return one, by the way)

And I implemented a very drafty version of the approach that I sketched in the first post, namely transforming the rays and leaving the model vertices untransformed. Some rough, ballpark(!) timing output from random clicks is...

old time 572.1999999992549 result (1234251.7463644503, -5086045.336428938, 3633312.886510718)
new time 280.5999999977648 result (1234251.7463644503, -5086045.336428938, 3633312.886510718)

old time 551.2000000029802 result (1234235.2367755438, -5086043.679150834, 3633322.2880171333)
new time 845.5999999977648 result (1234235.2367755438, -5086043.679150834, 3633322.2880171333)

old time 1135.0999999977648 result (1234205.9517392158, -5086040.159566937, 3633299.8229756234)
new time 280.6000000014901 result (1234205.9517392158, -5086040.159566937, 3633299.8229756234)

old time 1071.199999999255 result (1234170.020121471, -5086057.216095341, 3633337.9987499267)
new time 263.30000000074506 result (1234170.020121471, -5086057.216095341, 3633337.998749926)

It shows that...

• The results are equal
• The new time (in ms) is often significantly lower than the old time
  • (In very few cases, the new time is larger, but that might just be GC pauses or whatnot... to be examined)

[ggetz]

Thanks again for looking into this @javagl. I agree the ray transform optimization by itself is an improvement. If you're already put that together, we'd be happy to review a PR.

Separate from that appears to be that sphere picking issue, which we can look into separately.