looking at the functions of PolygonObject, I notice that two obvious C++ functions have made it into the Python interface: GetPolygonW and GetPolygonR.
Both functions return a PyCObject, which to my knowledge is a connector object between Python data and C++ data. But it's not included in the API documentation.
We also do not have examples for these functions in the Python code samples, and they aren't mentioned in a Python context on the Café. So, the question beckons: What can you use them for?
And is the actual way to set all polygons in a PolygonObject really a loop over SetPolygon, or am I missing something? There is no method SetAllPolygons as equivalent for SetAllPoints in PointObject. (Of course I can program such a function as a loop, but I feel as if I'm missing a trick here...)
PyCObject is not documented because it is part of the Python standard library. It is basically just a void pointer and its intended use is in a Python as a glue language scenario between two C applications. I also always found it a bit puzzling with which frequency this type is included in the SDK, given its rather limited utility for must users.
About the specific polygon stuff. You are right, writing polygons is awkwardly inefficient in Python. But there is no better way (or at least I am not aware of one).
@zipit Indeed! I never got the idea to look into the standard library. The type struck me as some special construct to link Python and C data types in C4D. (Well, it does, but differently from what I assumed.)
I guess the inefficiency of poly access in Python is due to the fact that Python doesn't have any kind of array that works like C arrays, so there must be an abstraction layer present. Ah well. Given the speed of Python, it's probably better not to do any polygon stuff there, anyway.
jeah, that is probably somewhat the reason. Although Python has true statically typed arrays, which also can be used to directly in-place manipulate C arrays (i.e. array.array), from what I understand it is quite cumbersome to achieve such linkage. This is probably the reason why Maxon does not bother in this case and others like for example vertex colors. Including these access points is still a bit puzzling though. Maybe they are somehow used internally? But I cannot think of a case where this would make sense.