Feature Request: Add in blanking/ghost cells to structured regular volumes (and structured spherical volumes for consistency)

[acbauer]

Hi,

Often times structured grids include a way to blank out certain cells in the grid. These blanked cells are cells that are not rendered. It would be great if OSPRay had a way to handle this through the structured regular volumes and structured spherical volumes instead of requiring converting to an unstructured volume and not passing these blanked cells to OSPRay, which would be much more inefficient (assuming that a relative few cells are blanked out).

Thanks,
Andy

[demarle]

VTK level feature request is here: https://gitlab.kitware.com/vtk/vtk/-/issues/18615

[johguenther]

@gregjohnson VKL introduced the float background parameter (also exposed in OSPRay) to define the value that is used when sampling an undefined region outside the volume domain (defaults to NaN). So, for float voxel types providing NaN should blank out those cells, shouldn't it? We'd need to confirm and officially define this. ...and have a solution for integer voxel types.

Using a hand-crafted transfer function with opacity zero for the ghost cells' value should also work, iff filter= OSP_VOLUME_FILTER_NEAREST.

[demarle]

Having the ghost marking information separate from the scalar array has uses that background and custom TF's in the array wouldn't cover. The one that comes to mind is AMR where you sometimes want to view above the finest resolution in which case you want averaged cells not invisible ones. Andy's use case might be something else though and manipulating the array in a Calculator filter to combine two arrays might work fine.

[acbauer]

Thanks for the feedback. I was confused about the outside the background parameter. I was thinking outside the volume domain meant external to the domain of the volume. Not sure how that would work but I'm not that familiar with all of this.

I was also thinking about putting together a hand-crafted TF with zero opacity but then this requires a bunch of extra manipulation and also gets away from zero-copy of the data as well. Maybe I'm not understanding they way you're suggesting @johguenther but my initial thoughts for implementation would end up quite hacky so I decided against my implementation.