zCallback for Offseter

[gjaegy]

Hi,

I'm currently evaluating how much work it would be to update our client code that was relying on Clipper1Lib, to use Clipper2Lib.

It seems we modified the initial Clipper1Lib in order to have the offsetter to support a zfill (zcallback) function. Do you have any plan to add that ?

Also, we did another modification, we changed the Z type to a struct (could be a template as well). This allows us to pack multiple things in that (alpha, elevation, etc.), reason why we also needed that z-interpolation callback for the offsetter.

So, I guess these are significant additions, I assume I'll have to port-back into Clipper2Lib - just wanted to check if these additions would be relevant for you (or not).

Cheers,
Greg

[gjaegy]

I guess I would now replace the int64_t type used for z by another template type, rather than a hardcoded struct...

[alexisnaveros]

Or one could adjust the API to have an arbitrary stride (in bytes) between input points, and an offset for custom data (like OpenGL/Vulkan vertex arrays). The pointer to the custom data is passed to the callback, to build new vertices as desired.

It's what I did in my C port, but I haven't merged Angus' bug fixes of the past 2 months, so that's not ideal.

[gjaegy]

Yes, that's another way of doing it...
I'm currently trying to figure out what part of the clipper.offset.cpp file to modify (so that the z values don't get lost in that process), it seems that class totally ignore the z component... Did you update that file so that is supports a z component properly ?

[alexisnaveros]

It was more a rewrite than an update (the offset stuff isn't that much code), but yes (kind of).

Every "offseted" point in the new shape comes strictly from a single origin point (it's not interpolated or anything). Look at ClipperOffset::OffsetPoint(); that's where all the points are added (plus OffsetOpenPath() if you care about the ends of open paths).

You could add a custom callback whenever points are pushed to the group.path_, probably just to copy the set of custom attributes of the origin point (unless you can look it up somewhere externally, always pass a void *context to callbacks!). The Clipper64 callback to fill custom vertex attributes would be different, as you can actually interpolate between 4 input points there.

[sergey-239]

The templating of a z member type would require to rebuild the whole library. If the library used in a project as a static lib, then it is not a big issue probably. The arbitrary stride is not an option as the PointZ has to be completely defined type to be an element of an std::vector. The possible trade off could be a PointZ defined with z member of type void *.

[gjaegy]

The templating of a z member type would require to rebuild the whole library. If the library used in a project as a static lib, then it is not a big issue probably. The arbitrary stride is not an option as the PointZ has to be completely defined type to be an element of an std::vector. The possible trade off could be a PointZ defined with z member of type void *.

Hi, I'm currently working on that. Having a 'z' member of type void* would involve some issues when new points get created (for instance, by the offseter). Assuming the void* reference a memory block that's stored externally, that makes it quite complex I think.

Or did I misunderstand you ?

[gjaegy]

The templating of a z member type would require to rebuild the whole library. If the library used in a project as a static lib, then it is not a big issue probably. The arbitrary stride is not an option as the PointZ has to be completely defined type to be an element of an std::vector. The possible trade off could be a PointZ defined with z member of type void *.

Introducing a new template typename "TZ" would require heavy changes in the whole library. Maybe an alternative option would be to use some macros instead, not as nice but much more localized:

#ifndef Z_TYPE
#define Z_TYPE int64_t
#define Z_DEFAULT_VALUE 0
#endif

One could potentially define this macro with another type and value prior to including the Clipper2Lib headers. However, this would mean the .cpp will have to contain the definition for the custom type. Which doesn't work really well.

Hmmm, not as simple as I initially have thought :/

[gjaegy]

OK I finally decided to go for the macro solution, since way less invasive. Drawback is that one would have to modify the clipper.core.h file to introduce the definitition of the custom structure used for "z". Not the best solution but that works for me.

For instance, I add the following code prior to the Z_TYPE default definition:

#define USINGZ 

#include "imCoreExt.h" 

struct Varying
{
	imS32 m_nID{ -1 };
	imEASTLArray<imFloat, 2> m_fAlpha{ -1, -1 };
	imBool IsValid() const { return m_nID != -1; }
};
inline std::ostream& operator<<(std::ostream& os, const Varying& point)
{
	//os << point.x << "," << point.y << "," << point.z;
	return os;
}
#define Z_TYPE Varying
#define Z_DEFAULT_VALUE Varying()

I've published a pull request with these changes, let me know if that's OK or not !

[alexisnaveros]

Yes, the whole memory management would have to be quite different to allow a custom amount of extra per-vertex data (which could be considered eventually, as I did get a 15-ish% performance boost when tweaking memory management).

The quick and easy solution is a Z struct (or union, for multiple Z structs), defined at compilation time.

[AngusJohnson]

Please put requests for new features in Discussion, and not in Issues (ref this post).