[Bug] GetShapeMaterialAtPosition() reports false results (probably due to precision errors)

[RavMahov]

Describe the bug GetShapeMaterialAtPosition() was reported work weirdly and report non-existing voxels. After an input from Dev Team we were hinted that this function is seeing voxels as spheres, which is nothing bad. But it seems that the sphere radius that the function uses to test for materials is big enough (that is, almost exactly the voxel "sphere" radius size) to produce precision errors and report things that it shouldn't, and that could be the reason why when "scanning" the door on the Basic map, the door know reports more voxels than it actually has (and there also appears to be an additional layer between knob and the door).

There was a brief conversation (with code and video), but I'm missing screenshots from the testing time: https://discord.com/channels/760105076755922996/786232592080437288/824059841202749461 The crosses in the video represent non-air voxels, and it can be seen that there are just too many of these (which varies by rotation, making it even more plausible that the sphere used to read the voxel has a radius that allows for rounding error-based flickering detection results.

To Reproduce Steps to reproduce the behavior:

1. Go to https://discord.com/channels/760105076755922996/786232592080437288/824059841202749461
2. Watch the video (direct link)
3. Copy code, use it in a basic weapon and try it out
4. (Very possibly) see error

Expected behavior If we try to check voxel data at position of the center of voxel, it should reliably report it instead of providing false data.

Screenshots Sorry, but screenshots were lost. We have a video instead

Environment

• Teardown Version 0.6.2 (patch 1)
• OS: Windows
• GPU: GTX 1080Ti (but happens on other cards too)
• Graphics driver version: shouldn't matter as it happened on different hardware and configurations reliably
• CPU: Intel i5 4670K (but happens on other CPUs too)

Additional context Scanning shapes is useful to determine their composition, and the function is useful for self-driving vehicles, so we can't exactly have it report false readings. If something is composed mostly of weak materials, but also contains reinforced layer, not detecting it could be fatal.

[tuxedolabs]

I can see the problem, just not sure how to handle it. The function is intentionally designed to give the shape material closest to the query point within a reasonable margin, not to determine if there space is empty/filled. The reason I do it this way is so that it will always work with results from raycasts/shapecasts, etc that could generate points on the edge of a voxel, thus due to floating point precision resulting in a zero value. Does that make sense? I could maybe add a flag to control this behavior. What's the intended use-case for getting exact values at voxel positions?

[MisterSirCode]

I can see the problem, just not sure how to handle it. The function is intentionally designed to give the shape material closest to the query point within a reasonable margin, not to determine if there space is empty/filled. The reason I do it this way is so that it will always work with results from raycasts/shapecasts, etc that could generate points on the edge of a voxel, thus due to floating point precision resulting in a zero value. Does that make sense? I could maybe add a flag to control this behavior. What's the intended use-case for getting exact values at voxel positions?

@tuxedolabs I believe this method is commonly used to create cameras / portals and other objects to show color on a 2D surface from somewhere else in the level. Im assuming that, with low quality precision, this would result in miscolored / missing or mispositioned pixels, which would break the appearance (Which is already somewhat low quality due to the minimal detail that can be derived from from raycasts without causing performance issues)

I believe mods like the Portal Gun mod and a few others do this

[nooitaf]

@tuxedolabs I use it to read out (export) complete voxel objects. I have to scale them up to 2.0 to make it work at the moment, as the "collision sphere"(?) doesn't scale with the voxel. Then they don't ever overlap and i get a correct reading.

Another optional solution (in my case) could be a possibility to "crawl" through the voxels of a shape. And maybe a GetShapeVoxelIndexAtPosition() for if a raycast is needed/used.

I can imagine some things where a perfect or partial copy of a shape could be useful. One example would be, the comparison between the original and a partially broken object. Lets say i have a duck, i read out all voxels and keep them around. Then i break it's beak off. Then i have a couple of voxels that will fix it. In the current state i would have lot's of overlaps or missing positions.

[tuxedolabs]

I have added a new API function in 0.8: GetShapeMaterialAtIndex that operated with integers instead. I also added a fourth return value to GetShapeSize (voxel size, including scaling) which together should resolve this issue and make it possible to very accurately traverse an entire voxel object.