Volumes have an offset in viewport, Eevee and Cycles. #85312

New Issue

Jacques Lucke · 2021-02-02T16:06:33+01:00

Jacques Lucke commented

2021-02-02 16:06:33 +01:00

We store volumes in OpenVDB grids. Voxels in those grids can be accessed using signed integer coordinates. In most cases a voxel can be thought of as a cube. The main question this task tries to answer is where the cube of the voxel with the coordinate (0, 0, 0) should be displayed and rendered.

Currently, the voxel (0, 0, 0) is rendered in the cube [0, 1]^3 (assuming no other transforms are applied). The "origin" voxel is not centered around (0, 0, 0) in world space. This can be seen in the image below.

The issue is, that OpenVDBs tools seem to expect that the (0, 0, 0) voxel is centered in world space. This can be seen when running the following code:

auto my_grid = openvdb::FloatGrid::create(0.0f);
auto accessor = my_grid->getAccessor();
accessor.setValueOn({0, 0, 0}, 1);

std::vectoropenvdb::Vec3s verts;
std::vectoropenvdb::Vec3I tris;
std::vectoropenvdb::Vec4I quads;
openvdb::tools::volumeToMesh(*my_grid, verts, tris, quads, 0.001f, 0.0f);

for (int i = 0; i < verts.size(); i++) {
std::cout << i << ": " << verts[i] << "\n";
}

This outputs:

0: [-0.333, -0.333, -0.333]
1: [-0.333, -0.333, 0.333]
2: [-0.333, 0.333, -0.333]
3: [-0.333, 0.333, 0.333]
4: [0.333, -0.333, -0.333]
5: [0.333, -0.333, 0.333]
6: [0.333, 0.333, -0.333]
7: [0.333, 0.333, 0.333]

When using these computed coordinates as vertex positions, the generated mesh will not be aligned correctly with the volume grid. Therefore, to correct the alignment, we currently have to add an offset every time we convert between volumes and meshes.

To me it seems like the best solution would be to change the rendering code, instead of adding the offset in many places. I haven't checked how other software handles this yet.

We store volumes in OpenVDB grids. Voxels in those grids can be accessed using signed integer coordinates. In most cases a voxel can be thought of as a cube. The main question this task tries to answer is where the cube of the voxel with the coordinate `(0, 0, 0)` should be displayed and rendered. Currently, the voxel `(0, 0, 0)` is rendered in the cube `[0, 1]^3` (assuming no other transforms are applied). The "origin" voxel is **not** centered around `(0, 0, 0)` in world space. This can be seen in the image below. ![image.png](https://archive.blender.org/developer/F9609392/image.png) The issue is, that OpenVDBs tools seem to expect that the `(0, 0, 0)` voxel is centered in world space. This can be seen when running the following code: ```lang=c++ ``` auto my_grid = openvdb::FloatGrid::create(0.0f); auto accessor = my_grid->getAccessor(); accessor.setValueOn({0, 0, 0}, 1); ``` ``` std::vector<openvdb::Vec3s> verts; std::vector<openvdb::Vec3I> tris; std::vector<openvdb::Vec4I> quads; openvdb::tools::volumeToMesh(*my_grid, verts, tris, quads, 0.001f, 0.0f); ``` ``` for (int i = 0; i < verts.size(); i++) { std::cout << i << ": " << verts[i] << "\n"; } ``` ``` This outputs: ``` 0: [-0.333, -0.333, -0.333] 1: [-0.333, -0.333, 0.333] 2: [-0.333, 0.333, -0.333] 3: [-0.333, 0.333, 0.333] 4: [0.333, -0.333, -0.333] 5: [0.333, -0.333, 0.333] 6: [0.333, 0.333, -0.333] 7: [0.333, 0.333, 0.333] ``` When using these computed coordinates as vertex positions, the generated mesh will not be aligned correctly with the volume grid. Therefore, to correct the alignment, we currently have to add an offset every time we convert between volumes and meshes. To me it seems like the best solution would be to change the rendering code, instead of adding the offset in many places. I haven't checked how other software handles this yet.

Jacques Lucke commented

2021-02-02 16:06:33 +01:00

Added subscribers: @JacquesLucke, @brecht

Hans Goudey commented

2021-02-02 16:46:41 +01:00

Added subscriber: @HooglyBoogly

Kévin Dietrich commented

2021-02-02 17:13:06 +01:00

Added subscriber: @kevindietrich

Brecht Van Lommel commented

2021-02-02 18:08:14 +01:00

I'm fine with changing the rendering code to be offset by half a voxel, it shouldn't really break compatibility much.

I couldn't find a convention in the OpenVDB docs, they give examples of how to handle both. But if the tools work this way I think it's a good choice.

@kevindietrich @JacquesLucke can either of you implement this for Cycles/Eevee/workbench?

I'm fine with changing the rendering code to be offset by half a voxel, it shouldn't really break compatibility much. I couldn't find a convention in the OpenVDB docs, they give examples of how to handle both. But if the tools work this way I think it's a good choice. @kevindietrich @JacquesLucke can either of you implement this for Cycles/Eevee/workbench?

JT Nelson commented

2021-02-03 04:11:35 +01:00

Added subscriber: @jta

Jacques Lucke commented

2021-02-03 15:18:21 +01:00

I'll make a patch for it.

Jacques Lucke self-assigned this 2021-02-03 15:18:31 +01:00

Jacques Lucke commented

2021-02-03 19:50:29 +01:00

I uploaded a patch in D10295. It's still work in progress. I also found a couple of issues in existing drawing code along the way (incorrect bounding box computation that lead to incorrect renders; dimensions of a bounding box were one unit too small; multiple_transforms is always set to true).

I uploaded a patch in [D10295](https://archive.blender.org/developer/D10295). It's still work in progress. I also found a couple of issues in existing drawing code along the way (incorrect bounding box computation that lead to incorrect renders; dimensions of a bounding box were one unit too small; `multiple_transforms` is always set to true).

Philipp Oeser commented

2021-02-16 19:05:33 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Raimund Klink commented

2022-01-24 11:32:18 +01:00

Added subscriber: @Raimund58

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Volumes have an offset in viewport, Eevee and Cycles. #85312