Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong picking index - Any clue ? #34

Open
Pourfex opened this issue Jul 7, 2023 · 1 comment
Open

Wrong picking index - Any clue ? #34

Pourfex opened this issue Jul 7, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@Pourfex
Copy link

Pourfex commented Jul 7, 2023

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
Copy link

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.

@tentone tentone added the bug Something isn't working label Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants