doyubkim / fluid-engine-dev

Fluid simulation engine for computer graphics applications

Home Page:https://fluidenginedevelopment.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bug in Bvh3<T>::build()

kentbarber opened this issue · comments

I have an emitter that just has a plane in it.
The plane is converted to an ImplicitSurface3 jet::SurfaceToImplicit3(plane)
The implicit surface is then added to an ImplicitSurfaceSet3.
Which is then added to a jet::VolumeParticleEmitter3.
This is used in an SPH solver.

Since the plane is not bounded then the call to isBounded will return false.
That means that the following code will not add anything to the bounds vector.

void ImplicitSurfaceSet3::buildBvh() const {
    if (_bvhInvalidated) {
        std::vector<BoundingBox3D> bounds;
        for (size_t i = 0; i < _surfaces.size(); ++i) {
            if (_surfaces[i]->isBounded()) {
                bounds.push_back(_surfaces[i]->boundingBox());
            }
        }
        _bvh.build(_surfaces, bounds);
        _bvhInvalidated = false;
    }
}

_bvh.build() does not check if the number of _surfaces is the same as the number of bounds.

Which then leads to an out of bounds error accessing the itemBounds in the _bvh.build() method.

void Bvh3<T>::build(const std::vector<T>& items,
                    const std::vector<BoundingBox3D>& itemsBounds) {
    _items = items;
    _itemBounds = itemsBounds;

    if (_items.empty()) {
        return;
    }

    _nodes.clear();

    for (size_t i = 0; i < _items.size(); ++i) {
        _bound.merge(_itemBounds[i]);   //Out of bounds.
    }
    std::vector<size_t> itemIndices(_items.size());
    std::iota(std::begin(itemIndices), std::end(itemIndices), 0);

    build(0, itemIndices.data(), _items.size(), 0);
}

Note that the final build() method also expects content in _itemBounds. And you can't just exit from these methods since then no bounds will be set for the plane and I do not believe it will then emit, although I haven't gotten that far in my debugging yet.

Awesome, thanks for finding this!

Potential fix is pushed to the branch shown above (fix-270). The temporary PR #272 still needs unit tests which should be added after PR #271 gets merged.

@kentbarber can you confirm the fix? Thanks!

Yes I can confirm that the changes made fixed the issue regarding having a plane in the scene as an emitter. This works fine now, thanks.