Wrong picking index - Any clue ?

[Pourfex]

Hello,
I have issues with picking (works well in Potree), been trying to fix it by going deep into potree's code and this typescript project.

    private static addPositionToPickPoint(
        point: PickPoint,
        hit: PointCloudHit,
        values: BufferAttribute,
        points: Points
    ): void {
        console.log(`values length ${ values.array.length } / index ${ hit.pIndex }`);
        point.position = new Vector3()
            .fromBufferAttribute(values, hit.pIndex)
            .applyMatrix4(points.matrixWorld);
    }

At the end we're getting a pIndex which corresponds to the bufferGeometry position index of the pcIndex's Node.
To find the final position, getting a vector3 from the bufferGeometry is indeed simple.

While logging the bufferGeometry values lenght and the pIndex; I have found that most of the time the pIndex is too high for the lenght of the bufferGeometry (.fromBufferAttribute will take in this code the 3*pIndex because of size of Vector3).

I tried concerning this issue :

• Debugging buffer's iBuffer and render target using Texture helper - they seems to match Potree's.
• See if we were missing nodes on the ray but that does not seems to be the case.

My current hypothesis is that the pick parameters of the pick material are wrong, and the pIndex value we're getting in the iBuffer is wrong aswell.

Wonder if someone had this issue or someone fixed it elsewhere ?

[YertofeX]

I'm having the exact same issue. Unfortunately, I haven't found a solution, but I did some experiments with custom point clouds, maybe the results will help in the future to find a fix.

I set up a testing environment using one of the official Potree examples, and loaded my point cloud in there to see the correct results, and be able to compare them with my viewer's results, which uses Potree Core.

The point cloud used, in human readable format:
<x> <y> <z> <r> <g> <b>

1 1 1 255 0 0
2 2 2 0 255 0
3 3 3 0 0 255
4 4 4 255 255 0
5 5 5 0 255 255
6 6 6 255 0 255
7 7 7 255 255 255
8 8 8 0 0 0

Hovering over each point, I get the following pIndexes:
1 1 1: pIndex: 0 (This is actually the correct hit for this point)
2 2 2: pIndex: 13
3 3 3: pIndex: 22
4 4 4: pIndex: 28
5 5 5: pIndex: 34
6 6 6: pIndex: 38
7 7 7: pIndex: 42
8 8 8: pIndex: 46

Hovering over the points in the potree example produces the correct result:
1 1 1: pIndex: 0
2 2 2: pIndex: 1
3 3 3: pIndex: 2
4 4 4: pIndex: 3
5 5 5: pIndex: 4
6 6 6: pIndex: 5
7 7 7: pIndex: 6
8 8 8: pIndex: 7

The position attribute in the node geometry is the same (and correct) Float32Array(24) in both cases:

0: 0
1: 0
2: 0
3: 1
4: 1
5: 1
6: 2
7: 2
8: 2
9: 3
10: 3
11: 3
12: 4
13: 4
14: 4
15: 5
16: 5
17: 5
18: 6
19: 6
20: 6
21: 7
22: 7
23: 7

So for example, hovering over the point at 6 6 6, the color of the hit pixel should be rgb(5, 0, 0), thus giving a pIndex of 5. With this, the coordinates as read from the position attribute should be:
x: position.array[3 * 5 + 0] --> 5
y: position.array[3 * 5 + 1] --> 5
z: position.array[3 * 5 + 2] --> 5
So 5 5 5 in the node's local space, which gets mapped to 6 6 6 in global coordinates.

What happens instead in my case when hovering over over the point at 6 6 6:
The color of the pixel is rgb(38, 0, 0), giving a pIndex of 38. We can already see that this is out of the range of the position array for all coordinates.

Since the node geometry's position attribute is correct, it leads me to believe the issue is due something with the material or the shaders it uses.