Using Clipper Offset with PathsD

[duncanspumpkin]

Hi, I'm wanting to use clipper offset with double coordinates but I'm not getting the results I'm expecting (jagged) and I think it might possibly be due to truncation of values when they are converted from PathsD to Paths64. Its a bit hard for me to show the results or my code for this but its basically:

        Clipper2Lib::PathsD paths;

        for (const auto &poly : polys)
        {
            Clipper2Lib::PathD path;
            for (const auto &point : poly)
            {
                path.push_back({point.x, point.y});
            }
            paths.push_back(path);
        }

        Clipper2Lib::ClipperOffset co;
        co.AddPaths(paths, Clipper2Lib::JoinType::Round, Clipper2Lib::EndType::Polygon);
        const auto result = co.Execute(offset);

        std::vector< std::vector< InternalVector2dD > > output;
        for (const auto &path : result)
        {
            std::vector< InternalVector2dD  > newPoints;
            for (const auto &point : path)
            {
                newPoints.push_back(InternalVector2dD (point.x, point.y));
            }
            output.push_back(newPoints);
        }

When I look at the function AddPaths I see that its just converting my doubles straight to integers using a static_cast (PathsDToPaths64->TransformPaths->TransformPath->Point::Point->Point::Init). I was sort of expecting there to be some scaling like in the ClipperD/Clipper64 classes. Am I meant to be scaling my coordinates before handing it to this function? Or is there some other obvious mistake I am making.

Hopefully this is enough information for some assistance.

[AngusJohnson]

Hi Duncan.

Yes, you're correct that ClipperOffset::AddPaths(const PathsD &p, ...) doesn't do any scaling and simply truncates to integer values.

And looking at this again now, I'm very much inclined toward removing this overloaded method and allowing only ClipperOffset::AddPaths(const Paths64 &p, ...), especially since the result of ClipperOffset::Execute will always be a Paths64 object. And this would avoid any scaling confusion such as you're experiencing now. Nor should this cause inconvenience, because the Clipper::Inflate() function would still accept PathsD objects, and it scales too (defaulting to 2 decimal places). And of course it also de-scales the result.

So in doing this, ClipperOffset would again only accept integer coordinates, and it would be up to the user to do their own scaling, or instead use the very simple InflatePaths function which is a wrapper for ClipperOffset.

[duncanspumpkin]

Thanks for that. I'll try use InflatePaths. Yes it would be good to remove the overload so hopefully others don't make my same mistake.