[BUG] NanoVDB math::ZeroCrossing with ray producing incorrect results #1846
Labels
Comments
|
Some additional info/correction: Here's a modified version of the test program that works with OpenVDB 11.0.1: #define NANOVDB_USE_OPENVDB
#include <openvdb/openvdb.h>
#include <openvdb/io/Stream.h>
#include <openvdb/tools/LevelSetSphere.h>
#include <openvdb/tools/RayIntersector.h>
#include <nanovdb/NanoVDB.h>
#include <nanovdb/util/Ray.h>
#include <nanovdb/util/HDDA.h>
#include <nanovdb/util/CreateNanoGrid.h>
#include <fmt/format-inl.h>
int main(int argc, char **argv)
{
openvdb::initialize();
std::ifstream in("/home/jbijlsma/tmp/box.rotated.vdb");
openvdb::io::Stream stream(in);
openvdb::FloatGrid::Ptr grid = openvdb::DynamicPtrCast<openvdb::FloatGrid>(stream.getGrids()->front());
auto handle = nanovdb::createNanoGrid<openvdb::FloatGrid, float, nanovdb::HostBuffer>(*grid);
nanovdb::NanoGrid<float> *nano_grid = handle.grid<float>();
const auto vdb_voxel_size = grid->voxelSize();
const auto nano_voxel_size = nano_grid->voxelSize();
std::cerr << "OpenVDB voxel size: " << vdb_voxel_size << std::endl;
std::cerr << "NanoVDB voxel size: " << nano_voxel_size[0] << "," << nano_voxel_size[1] << "," << nano_voxel_size[2] << std::endl;
const double voxel_size = vdb_voxel_size.x();
const openvdb::CoordBBox grid_bbox = grid->evalActiveVoxelBoundingBox();
const double max_world_dim = std::max(std::max(grid_bbox.dim().x(), grid_bbox.dim().y()), grid_bbox.dim().z()) * voxel_size;
const int image_width = 101;
const int image_height = 101;
const float viewport_width = 20.0f;
const double viewport_height = ((double) image_height / image_width) * viewport_width;
{
std::ofstream out("trace.nano.out");
for (int j = 0; j < image_width; j++)
{
int i = 50;
const float x = ((static_cast<float>(j) / static_cast<float>(image_width - 1)) - 0.5f) * viewport_width;
const float y = ((static_cast<float>(image_height - i - 1) / static_cast<float>(image_height - 1)) - 0.5f) * viewport_height;
const auto accessor = nano_grid->tree().getAccessor();
const nanovdb::Ray<float> ray({ x, y, 20.0f }, { 0.0f, 0.0f, -1.0f });
nanovdb::Ray<float> ray_index = ray.worldToIndexF(*nano_grid);
float t0;
nanovdb::Coord ijk;
float v;
const bool crossing = nanovdb::ZeroCrossing(ray_index, accessor, ijk, v, t0);
out << fmt::format("{}: {:#6.2f}\t{:#6.2f}\t{:#6.2f}\t{:#6.2f}\t{:6d}{:6d}{:6d}\t{:#6.2f}\n",(int) crossing, x, y, ray_index.eye()[0], ray_index.eye()[1], ijk[0], ijk[1], ijk[2], t0);
}
}
{
std::ofstream out("trace.openvdb.out");
for (int j = 0; j < image_width; j++)
{
int i = 50;
const float x = ((static_cast<float>(j) / static_cast<float>(image_width - 1)) - 0.5f) * viewport_width;
const float y = ((static_cast<float>(image_height - i - 1) / static_cast<float>(image_height - 1)) - 0.5f) * viewport_height;
openvdb::tools::LevelSetRayIntersector<openvdb::FloatGrid, openvdb::tools::LinearSearchImpl<openvdb::FloatGrid, 2, double>> intersector(*grid);
openvdb::Vec3d xyz;
double t0;
openvdb::math::Ray<double> ray{ { x, y, 20}, { 0.0f, 0.0f, -1.0f } };
const openvdb::math::Ray<double> ray_index = ray.worldToIndex(*grid);
const bool crossing = intersector.intersectsIS(ray, xyz, t0);
out << fmt::format("{}: {:#6.2f}\t{:#6.2f}\t{:#6.2f}\t{:#6.2f}\t{:#6.2f}{:#6.2f}{:#6.2f}\t{:#6.2f}\n",(int) crossing, x, y, ray_index.eye()[0], ray_index.eye()[1], ray_index(t0).x(), ray_index(t0).y(), ray_index(t0).z(), t0);
}
}
return 0;
}This produces the exact same output as the previous progream with the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Operating System: Ubuntu 22.04
Version / Commit SHA: OpenVDB 11.0.1
Other: gcc 10.5.0
Describe the bug
I'm trying to intersect a level-set grid with a Ray in NanoVDB, and I'm getting back strange (wrong) results that don't look like they might be from incorrect usage.
Specifically, it looks as if somewhere internally in the NanoVDB HDDA, ray coordinates are being jumbled up, producing a combination of an off-by-one error and some inversion or bit reversal or something similar.
To Reproduce
Since this is very hard to explain in words I wrote a standalone test program to debug and qualify the NanoVDB raytrace result against the OpenVDB raytrace interface.
What the following program does is create a level-set sphere with radius 10 and voxel size 1, then raytrace a horizontal scanline through the middle of the sphere, 101 samples in the x-range [-10, 10]. I do this for both NanoVDB and OpenVDB, and print the intersection to a CSV file with the following columns:
I'm aware the OpenVDB LevelSetIntersector returns the actual level-set surface intersection, while the NanoVDB
math::ZeroCrossingwith a ray returns the ray-voxel intersection and I need to do further march to the surface, but for demonstrating the bug, this example suffices.Program source:
Output for OpenVDB:
Output for NanoVDB:
Expected behavior
As is clear from the CSV output, the intersector is not finding intersections for exactly matching rays (as confirmed by the first 5 columns).
In the NanoVDB result, the first 5 rays in the world-space x-range [-10.0, -9.20] fail to find any intersection at all, and the intersection times of all other rays are also off compared to the OpenVDB result. I would expect these rays to report an intersection and return the voxel index coordinate directly behind the surface intersection, and an intersection time that gives me the time at which the ray hits the voxel that contains the iso-surface. I would then use those to find the actual iso-surface intersection (if there is one, I guess the ray can also shear past the surface at <1 voxel distance) using root finding or sphere tracing.
One interesting piece of information is that the error in the results does not seem to be just an off-by one error, if I try to ray-march using the
t0returned by themath::ZeroCrossingfunction, I see some strange grid-dependent behavior.I've attached a rendering of what happens when I try to take 2 index-space voxel steps back from the
ijkreported byZeroCrossing, sample the distance value there and atijk, and check if they have different signs. The image is color-coded like this: light gray pixels are hit and a sign change was found, dark gray pixels are hit but no sign change was found, black pixels are not hit at all.The text was updated successfully, but these errors were encountered: