R19: SplitPolygon and Ngon indices

fwilleke80

We have discovered a strange behavior in Modeling::SplitPolygon() in conjunction with Ngons, where it fails, depending on the indices.

It should, according to the documentation take an ngon index while what works is polygon indices. All you need to make this function fail is to give it the index of an ngon that doesn't contain any polygons that have the same index. We have created a very simple example plugin demonstrating this.

https://files.frankwilleke.de/index.php/s/BN0qwh8n6WrLJVa

Compile the project (only Windows project file included), run Cinema, and open the included C4D file. Open the console window, and switch to "Gouraud Shading (Lines)". Select the "Ngon Debug Tool" from the plugins menu, and click on the geometry in the viewport. See the split fail.

The question is easy: How do we make this work?

Thanks in advance & greetings from Berlin,
Frank

Braeburn

Frank kindly uploaded the example plugin for me. I would like to add a few things. The strange behavior in Modeling::SplitPolygon() is just one of many confusing observations with ngon indices.

For me the main questions are:
What exactly is an ngon index?
What needs to be done, to create an ngon index, which works consistently with all the ngon functions in the SDK?

In the example above we assume that ngon indices start at 0, which seems to be incompatible with some of the methods in Cinema's Modeling class.

If I use the Modeling::GetEdgeNgons() function to get the shared ngons of an edge, Cinema returns 9 as an index for the first ngon we want to split, and 10 for the next ngon we want to split. If I use those indices the Modeling::SplitPolygon() function works fine.

So it seems the indices are somehow offsetted. Maybe ngon indices start after the polygon indices?

On the other side, the polygon to ngon index conversions returned by the function PolygonObject::GetPolygonTranslationMap() seems to have no offsets and are not compatible with functions like Modeling::SplitPolygon() and Modeling::GetEdgeNgons().

Is somebody able to clarify the general logic behind ngon indices in Cinema 4D?

Thank you very much!
Best regards
Tim

r_gigante

Hi Tim and Frank, thanks for writing here.

With regard to the question initially raised by @fwilleke80, the issue is cause by the ngon index that should actually passed to the SplitCommand(). Whilst your code is correct and properly follow what's written in the documentation unfortunately doesn't reflect how internally the old modelling kernel works.
Without entering the details of its design the code should be adapted in order to take in consideration both the count of ngon (> 4 points) and of polygons (3 or 4 points) and act accordingly as in code snippet below:

...
Int32 ngonIdx = 0;
Int32 pt1Idx = 4;
Int32 pt2Idx = 7;

const Int32 polyCnt = polyObj->GetPolygonCount();
const Int32 ngonCnt = polyObj->GetNgonCount();
if (ngonIdx < ngonCnt)
	ngonIdx += polyCnt;
...

At the same time to replying to @Braeburn the ngon index values which are then shown in the UI are actually "polished" values without no offset leading to an evident confusion in external developers. Actions will be took to improve the documentation in this regard.

For any further detail I also recommend to give a look at the Get Outer Edges thread where I wrote in the past about ngon representation and related methods.

Best, Riccardo

Braeburn

@r_gigante Thank you very much for your help, Riccardo!

The suggested method of calculating the ngon index works fine with the Modeling::SplitPolygon() function, but functions like Modeling::GetEdgeNgons() sometimes return unexpected indices, which seem to be based on a different logic.

I have updated the demo plugin and also included an image (NgonIndexProblem.png) in the zip file, which explains the problem:

https://files.frankwilleke.de/index.php/s/EpGg1TkdzIemWJl

In this case Modeling::GetEdgeNgons() and Modeling::GetPointNgons() returns indices which seem to be a confusing mix of ngon and polygon indices (or indices with and without offsets).

Do you have any more ideas?

Thanks in advance,
Tim