Page MenuHome

Fix T85312: Volumes have an offset in Workbench, Eevee and Cycles.
Changes PlannedPublic

Authored by Jacques Lucke (JacquesLucke) on Feb 3 2021, 7:38 PM.

Details

Summary

I had to change a few more places than I've thought at first, unfortunately.

This seems to fix the behavior for Workbench, Eevee and Cycles.

The patch can be tested with this file. It uses a temporary change in the Mesh to Volume modifier that makes it output a single voxel every time.

The voxel should be centered at the world origin:

Diff Detail

Repository
rB Blender
Branch
volume-offset (branched from master)
Build Status
Buildable 12723
Build 12723: arc lint + arc unit

Event Timeline

Jacques Lucke (JacquesLucke) requested review of this revision.Feb 3 2021, 7:38 PM
Jacques Lucke (JacquesLucke) created this revision.
Jacques Lucke (JacquesLucke) retitled this revision from Fix T85312: Volumes have an offset in viewport, Eevee and Cycles (WIP). to Fix T85312: Volumes have an offset in viewport, Eevee and Cycles..Feb 8 2021, 6:48 PM
Jacques Lucke (JacquesLucke) edited the summary of this revision. (Show Details)
Jacques Lucke (JacquesLucke) retitled this revision from Fix T85312: Volumes have an offset in viewport, Eevee and Cycles. to Fix T85312: Volumes have an offset in Workbench, Eevee and Cycles..Feb 8 2021, 6:51 PM
Jacques Lucke (JacquesLucke) added inline comments.
source/blender/modifiers/intern/MOD_mesh_to_volume.cc
258

I won't commit this part, but it is very useful to see if the patch is actually working.

source/blender/gpu/shaders/material/gpu_shader_material_volume_info.glsl
18

Can't you use a GPU_SAMPLER_CLAMP_BORDER (using GPU_texture_wrap_mode(false, false))? Border color is vec4(0,0,0,1) by default.

source/blender/gpu/shaders/material/gpu_shader_material_volume_info.glsl
18

Unfortunately, this does not seem to work (although I also don't know what these clamping modes do exactly).
Using P1950 on top of this patch results in

It seems to clamp on different values than 0 and 1.

I should note that this is related to the fact that BKE_volume_grid_bounds does not return the best possible bounding , because it uses evalLeafBoundingBox instead of evalActiveVoxelBoundingBox (the latter of which results in a more accurate bounding box but is more costly).
An alternative fix would be to change BKE_volume_grid_bounds, but I found that the drawing code should be correct even if this function returns a non-optimal bounding box.

Clément Foucault (fclem) added inline comments.
source/blender/gpu/shaders/material/gpu_shader_material_volume_info.glsl
18

You are right the texture might interpolate until -0.5/textureSize.

Then forget about the sampler trick.

However you can check out of bounds like this to aviod the double check:

any(greaterThan(abs(coord - 0.5), vec3(0.5)))
This revision is now accepted and ready to land.Feb 13 2021, 1:42 PM
source/blender/gpu/shaders/material/gpu_shader_material_volume_info.glsl
18

That makes sense. There is similar check in volume_frag.glsl with can be simplified as well, that should be done in a separate patch though.

Brecht Van Lommel (brecht) requested changes to this revision.Feb 15 2021, 2:56 PM
Brecht Van Lommel (brecht) added inline comments.
intern/cycles/render/image_vdb.cpp
150–152

It seems the NanoVDB code path was not fixed, we use that by default for releases.

This revision now requires changes to proceed.Feb 15 2021, 2:56 PM
intern/cycles/render/image_vdb.cpp
150–152

Ah right, didn't test the NanoVDB path yet.

I just noticed that both code paths result in different renders without this patch!
NanoVDB seems to draw voxels a bit larger (in the image it looks like it is even larger than the computed bounding mesh).

With NanoVDB:

Without NanoVDB:

Will need to look at this in more detail.

Jacques Lucke (JacquesLucke) planned changes to this revision.Feb 19 2021, 12:38 PM

I'll continue with patching the NanoVDB code path when T85736 is fixed.