H'H
H'H

Reputation: 1680

Boost intersection two line segments in 3D

I try to use boost geometry to calculate intersection of two line segments in 3D.

Here is piece of code:

typedef boost::geometry::model::point<double, 3, boost::geometry::cs::cartesian> boost3dPoint;
typedef boost::geometry::model::segment<boost3dPoint> boost3dSegment;

const boost3dPoint bp0(0, 0, 0);
const boost3dPoint bp1(2, 0, 0);
boost3dSegment lineP(bp0, bp1);

// line m
const boost3dPoint bm0(1, 1, 2);
const boost3dPoint bm1(1, -1, 2);
boost3dSegment lineM(bm0, bm1);

std::vector<boost3dPoint> output;

boost::geometry::intersection(lineP, lineM, output);

if(output.size() == 0)
{
  result.intsec = false;
}
else if(output.size() == 1)
{
  std::cout << "test: output.size() " << std::endl;
  result.intsec = true;
  boost3dPoint bresult = output[0];
  mesh::Point cross(bresult.get<0>(), bresult.get<1>(), bresult.get<2>());
  result.pon = cross;
}
else
{
  // it may line on each other, cosider as no intersection for now
  result.intsec = false;
}

It is obvious that there is no intersection for above case, but it still returns result: ( 1, 0, 6.94593e-310 )

Does it only work in 2D?

Upvotes: 3

Views: 1954

Answers (1)

sehe
sehe

Reputation: 392833

Looks to me that indeed it works only for 2d cases. This is surprising because usually these constraints are asserted quite aggressively pro-actively by the library.

However, with the following test cases, it's pretty clear that the z coordinate value is just unitialized/indeterminate:

Live On Coliru

#include <boost/geometry/geometries/point.hpp>
#include <boost/geometry/core/cs.hpp>
#include <boost/geometry/io/io.hpp>
#include <boost/geometry/io/wkt/stream.hpp>
#include <boost/geometry/geometries/segment.hpp>
#include <boost/geometry/algorithms/intersection.hpp>
#include <boost/geometry/algorithms/correct.hpp>

#include <iomanip>
#include <fstream>
#include <iostream>

#if 0
#include <boost/multiprecision/cpp_dec_float.hpp>
typedef boost::multiprecision::cpp_dec_float<50> dec_float_backend;
typedef boost::multiprecision::number<dec_float_backend, boost::multiprecision::expression_template_option::et_off> T;
#else
typedef int T;
#endif

typedef boost::geometry::model::point<T, 3, boost::geometry::cs::cartesian> boostPoint;
typedef boost::geometry::model::segment<boostPoint> boostSegment;

int main() {
    std::cout << std::setprecision(std::numeric_limits<double>::max_digits10+2);

    for (auto&& segments : {
                // a simple test with intersection [ 5,0,0 ]
                std::make_pair(
                    boostSegment(boostPoint(0 , 0 , 0), boostPoint(10, 0 , 0)),
                    boostSegment(boostPoint(+3, +1, 0), boostPoint(+7, -1, 0))
                ),
                // the test from the OP:
                std::make_pair(
                    boostSegment(boostPoint(0, 0, 0), boostPoint(2, 0, 0)),
                    boostSegment(boostPoint(1, 1, 2), boostPoint(1, -1, 2))
                ),
            })
    {
        std::vector<boostPoint> output;
        boost::geometry::correct(segments.first); // just in case o.O
        boost::geometry::correct(segments.second);
        boost::geometry::intersection(segments.first, segments.second, output);

        std::cout << "Intersecting " << segments.first << " and " << segments.second << "\n";
        std::cout << "Output size: " << output.size() << " ";
        if (!output.empty()) std::cout << output[0];
        std::cout << "\n";
    }
}

On my local system the output was

Intersecting LINESTRING(0 0 0,10 0 0) and LINESTRING(3 1 0,7 -1 0)
Output size: 1 POINT(5 0 -133276928)
Intersecting LINESTRING(0 0 0,2 0 0) and LINESTRING(1 1 2,1 -1 2)
Output size: 1 POINT(1 0 -133276928)

And on the next run

Intersecting LINESTRING(0 0 0,10 0 0) and LINESTRING(3 1 0,7 -1 0)
Output size: 1 POINT(5 0 1)
Intersecting LINESTRING(0 0 0,2 0 0) and LINESTRING(1 1 2,1 -1 2)
Output size: 1 POINT(1 0 1)

valgrind confirms that the value is indeterminate:

==13210== Conditional jump or move depends on uninitialised value(s)
==13210==    at 0x4EBFE9E: std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<long>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, long) const (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==13210==    by 0x4EC047C: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, long) const (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==13210==    by 0x4ECC21D: std::ostream& std::ostream::_M_insert<long>(long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==13210==    by 0x401549: main (write.hpp:62)

I think one way or the other this smells like an issue that could be reported with the library developers

For you convenience, the "simple test" case that I added is actually 2D only looks like this:

enter image description here

Upvotes: 1

Related Questions