Point cloud display issue with vsg::PagedLOD: cannot make low-res and high-res child node display simultaneously

[geocapp]

Point cloud display issue with vsg::PagedLOD: cannot make low-res and high-res child node display simultaneously

Summary

When porting our point cloud loader from osg::PagedLOD to vsg::PagedLOD, we hit a behavioral difference that breaks our rendering: in OSG we can make the low-resolution and high-resolution child nodes visible at the same time by giving them overlapping ranges. In VSG, once the high-res child is loaded and within range, the low-res child is skipped, so there is no low-res "base layer" under the point cloud while the high-res data is being displayed. This causes visible holes / incorrect point cloud display.

I'd like to confirm whether this is intended by design, and what the recommended approach is for point clouds that need a always-present coarse layer.

Repositories

• VSG implementation: https://github.com/geocapp/vsgPotree
• OSG implementation (reference, works as expected): https://gitee.com/osg_opensource/osg-potree

The OSG version uses overlapping ranges on osg::PagedLOD and the low-res and high-res children display simultaneously. But vsg::PagedLOD cannot be configured this way.

What we do

Roughly (simplified):

// OSG - works: low-res and high-res visible at the same time
osg::ref_ptr<osg::PagedLOD> plod = new osg::PagedLOD;
plod->setRangeMode(osg::LOD::DISTANCE_FROM_EYE_POINT);
plod->setRange(0, 0.0f, FLT_MAX);
plod->setRange(1, 0.0f, 1000);

// VSG - low-res child is skipped once high-res is loaded/in range
auto plod = vsg::PagedLOD::create();
pagedLOD->children[0].minimumScreenHeightRatio = 0.5;
pagedLOD->children[1].minimumScreenHeightRatio = 0.0;

Visual comparison

The first image is the VSG effect, the second image is the OSG effect. At the same position, the VSG display has fewer points.

[robertosfield]

Yes, this is by design. This helps reduce the amount of data and number of comparisons that need to be done which lowers CPU overhead.

[geocapp]

Thanks, understood — skipping the low-res child reduces data comparison, lowering CPU overhead. Makes sense as the default.

Could this be made configurable? E.g. add a parameter controlling whether the low-res child is still evaluated/rendered when the high-res child satisfies the range condition. Default false keeps the current behavior (lowest CPU overhead); setting it to true would allow the low-res child to still be evaluated/rendered when the high-res child satisfies the range condition, so both can display simultaneously.

[robertosfield]

The point of the design is to avoid the extra data and comparisons, so adding data and comparison as an option would rather defeat that.

Potentially you could subclass your own PagedLOD and customize the comparisons.

[geocapp]

Hi Robert, thanks for the explanations — it's good to know this behaviour is intentional, and the reasoning about avoiding the extra data and comparisons makes sense.

Following up on your suggestion, I've tracked down where the decision about which child of a vsg::PagedLOD gets rendered is made: it's in RecordTraversal, specifically in void RecordTraversal::apply(const PagedLOD& plod) (src/vsg/app/RecordTraversal.cpp). The high res child (children[0]) is evaluated first (lines 189–197), if it satisfies the range condition, it is traversed followed by an early return — which is what skips the low res child (children[1], checked later at lines 247–259):

// check the high res child to see if it's visible
{
    const auto& child = plod.children[0];

    auto cutoff = lodDistance * child.minimumScreenHeightRatio;
    bool child_visible = sphere.r > cutoff;
    if (child_visible)
    {
        ...
        if (child.node)
        {
            // high res visible and available so traverse it
            child.node->accept(*this);
            return;  // <- the low res child below is skipped
        }
        ...
    }
    ...
}

I've had a go at the subclassing approach, writing my own RecordTraversal subclass that overrides apply(const PagedLOD&) so that both children are traversed when they are both in range. However, I haven't been able to work out how to get the viewer to actually use my subclass

[geocapp]

I am very sorry, you are right. I found that the void accept(RecordTraversal& visitor) const method of vsg::PagedLOD can be overridden; it is a virtual function of vsg::Object.Thank you very much again. (Result: https://github.com/geocapp/vsgPotree/blob/master/core/vsgPotree/AdditivePagedLOD.h)