Volume samplingRate and scaling

[paulmelis]

In #290 @jeffamstutz clearified the definition of the samplingRate parameter:

What exactly is the unit of this value, is it related to world-size, cell-size, volume bbox, ...?

Cell size: it represents the average number of cells per-sample taken along the ray.

To me this sounds like volume sampling density is based purely on the grid density, regardless of the actual world-space cell size. However, here's what I see with the same volume data that's scaled by factors 1/2, 1 and 2 respectively:

This is with samplingRate 1 for all three cases.

I haven't checked the code but could it be that the samplingRate is actually used to compute a world-space step size based on the untransformed volume, which is then used to step through the transformed volume? And it is therefore not independent of the volume scale?

[johguenther]

Is this with v2.0a and pathtracer (looks like it)? samplingRate only applies to Raymarching / SciVis, and is currently even not strictly interpreted according to above definition in v2 scivis.

I'd like that samplingRate does not change the appearance of the volume much, but scaling it should (thus samplingRate and world-space density/opacity should be independent from each other).

[paulmelis]

This is with the pathtracer and latest version-2.0.x version. The scivis renderer doesn't have working volume scaling/transform in my tests.

samplingRate only applies to Raymarching / SciVis, and is currently even not strictly interpreted according to above definition in v2 scivis.

Ah, that explains a lot. Might be handy to add a note in the docs of OSPVolumetricModel then, as it is listed as a general parameter there.

I'd like that samplingRate does not change the appearance of the volume much, but scaling it should (thus samplingRate and world-space density/opacity should be independent from each other).

Hmm, I guess my feeling is the opposite: you pick a sampling rate based on the underlying volume data, regardless of the size a volume is rendered at.

[johguenther]

Right, we are currently reworking OSPVolumetricModel for that reason.

Probably bad wording by me:

• yes, samplingRate should be relative to the volume resolution, changing it changes performance and "crispness", but should not change the overall "transparency"
• but (externally) resampling the volume and then scaling it to have the same world-space size as before should also result in the same overall transparency

[paulmelis]

but (externally) resampling the volume and then scaling it to have the same world-space size as before should also result in the same overall transparency

Just to confirm: with VolumetricModel's densityScale parameter in the current API version you can scale up/down a volume and compensate (per volumetric model) for density increase/loss by decreasing/increasing densityScale in response? At least, that's what I think I'm seeing in my tests.