tentone / potree-core

Potree point cloud viewer library core components for easier integration in a three.js project.
https://tentone.github.io/potree-core/
Other
178 stars 57 forks source link

Wrong picking index - Any clue ? #34

Open Pourfex opened 1 year ago

Pourfex commented 1 year ago

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 :

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 commented 1 year ago

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.