Feature resolution is unexpectedly impacted by the size of the bounding box about libfive HOT 3 OPEN

I think the issue might be that it relates to the dimensions at all -- I think typically a setting like resolution would refer to a certain amount of detail per unit, regardless of how many units large the document is. So it's more like each axis should get a certain number of subdivisions multiplied by its size.

from libfive.

This is a somewhat confusing side-effect of how we pick the max subdivision level in region.hpp:

    /*
     *  Returns a version of this region that has the level set
     *  based on the given minimum feature.
     *
     *  This lets us do subdivision without worrying that the termination
     *  condition (of a cell side being < min_feature) is dependent on
     *  floating-point accuracy.
     */
    Region<N> withResolution(double min_feature) const {
        const auto min_dimension = (upper - lower).minCoeff();
        const auto level = ceil(fmaxf(0.0f, logf(min_dimension / min_feature)) /
                                logf(2));
        return Region<N>(lower, upper, perp, level);
    }

The number of octree subdivisions is set by the lowest dimension, so I think that going from [10, 10] → [-1, 6] must be reducing it in your example.

Maybe it should be set by the largest dimension instead?

from libfive.

I agree that this should be per unit, and not dependent on the size of the bounding box. It also has a huge impact on exported STL size - settings that produce no artifacts with a smaller bounding box produce significantly larger files (multiple GiBs in my case), whereas a bounding cube produces no artifacts at default settings and order of magnitude smaller files.

from libfive.