Orthogonal lines glitch in volume rendering #75
Comments
NBickford-NV
added a commit
that referenced
this issue
Nov 12, 2020
…75) in rayDeepBrick and raySurfaceTrilinearBrick. Also hides other artifacts in gResample and gSprayDeposit by using a larger value of epsilon. Partly fixes gvdbRaytrace by using trilinear interpolation instead of tricubic (since tricubic requires an apron size of 2 for correctness, which isn't supported yet.) Finally, adds some more comments to HDDAState. Short version: If one still sees artifacts, they should try using VolumeGVDB::SetEpsilon(0.01f, 256); this seems to fix the remaining inter-brick volume artifact, while introducing some banding artifacts that are hard to see. I have some ideas for an HDDA approach that might avoid having to use an epsilon in the algorithm at all. For the artifacts in issue #99, it turned out that there were two issues in raySurfaceTrilinearBrick. One was that a line that quantized samples to discrete increments of t was commented out. Since the value of t when entering a brick otherwise depends on where within a voxel the ray entered the brick (I think), this led to visible bands the size of voxels. rayDeepBrick also had this problem, except there the issue was that quantization was performed after determining the voxel position, instead of before. The other issue in raySurfaceTrilinearBrick was that the loop to skip empty voxels inside bricks (which appears to have been intended as an optimization, but I'm not sure how effective it was) was incorrect - it would always step by SCN_DIRECTSTEP at least once, even if the initial sample was inside a brick. Together, these two issues appear to have been responsible for visible banding along the planes separating bricks, and for visible gaps between bricks in the volume view of g3DPrint and several other samples. However, volume rendering isn't totally artifact-free on all samples: in some samples, positioning one's camera just right and at a particular range of distances - such that one of the planes between bricks is greatly foreshortened - will show floating-point glitches between bricks. (This only seems to happen for some planes and on some samples - e.g. I haven't seen it on g3DPrint yet - but is possible to reliably reproduce on gDepthMap and gInteractiveGL). This appears to be due to the value of epsilon, which is used in rayCast to move samples slightly into nodes. In these cases, setting epsilon to a larger value - e.g. 0.01f - using VolumeGVDB::SetEpsilon(0.01f, 256) - appears to fix these artifacts, although it adds some subtle banding artifacts that look like circles in gDepthMap. As such, I've only applied this fix to gResample and gSprayDeposit, where it doesn't appear to add new visible artifacts. I'll probably take a look at replacing HDDAState with a new approach that expresses index-space position differently; hopefully this should avoid having to use an epsilon, although functions that access HDDAState's class members directly will probably have to be modified. This also fixes some problems with gSprayDeposit! It turns out that some artifacts were because not all aprons were being updated. Another issue is that gvdbRaytrace ignored the shading method passed to it and uses tricubic intersection instead. Because tricubic intersection technically requires an apron size of 2 (which isn't supported at the moment), this lead to rays sometimes intersecting the boundaries between bricks, which presented as adding density to spaces in the air. Changing gvdbRaytrace to use trilinear intersection instead fixes this - but the correct solution would be to respect the shading parameter passed to the function.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version: GVDB 1.1
Commit: 1f269ce
Current behavior:
Rendering volumetric data with the built-in render kernel (SHADE_VOLUME) produces a visual artifact (1px wide white orthogonal line) that appears to be along the brick boundaries.
Research:
The visual output depends on the configuration of the topology (in particular, on the last argument of GVDB::Configure method).
The glitch is only apparent when
F_LINEARinterpolation is used and the resolution is sufficiently large (tested on 3840x2160).Below is a detail of the visual glitch:
The text was updated successfully, but these errors were encountered: