Just check it manually:

        if currDoc.GetChanged() :
            c4d.gui.MessageDialog(c4d.plugins.GeLoadString(IDS_MSG_PROJECTCHANGED))
        else :
            c4d.documents.KillDocument(currDoc) # works but ignores change status

@del said in OBJ Export Options:

Thanks for your help, that worked. I swear that the documentation and what the SDK expects changes every couple of years. Several years ago I'd try words and I'd be told to use numbers and now it seams as if numbers work for some things but words are required for others. It can be a bit confusing for me at times but at least I have a working script again.

There are actually some values for which no constants exist, so you have to use numbers. Nevertheless - those "constants" (I write it in quote marks because Python doesn't have real constants, these are actually variables but you must never change them) are representing only numbers, they're not strings.

Constants are a common method to define numberic values because 1. if they change internally, you don't need to change your code because the constant will now refer the new value, and 2. it's more readable. So I understand why Maxon offers these constants. If you really need to you could use the numeric value instead (= 4093 in this case), but that is not recommended and only done when there really is no constant.

(In the latter case, you normally define your own constant just in case you need to change it later - then you have one change point instead of many, and an easy readable way to identify the purpose of that number.)

Just to clarify, I always thought when the documentation showed 'Parameter Type: int' that it meant a number and the number was representative of the numerical position in the list. You mentioned "numeric value of the five options shows that they are between 4092 and 4096". Where did you find those numbers? I don't see that in the Python documentation.

Well, the list positions are not necessarily the corresponding numbers. Have you ever created a list field in user data? You will notice then that for every entry you state an id and a text, the position in the list is not enough to define the ID. In many cases the ID and the position in the list field are the same, so you define text 0, text 1, text 2 etc. just as you expect.

But that's not needed (line index and ID may be vastly different), and in fact there are dropdowns in the C4D GUI where this is not the case! (I'm not going into detail why.)

If the API documentation lists constants, you're better off using these constants, for the reasons I just mentioned. If you want the numbers for the constants, just type them into the Python Console and press return, so Python shows you the value. If you get no value, prefix it with "print ", although that should only happen if the value of that constant is None.

If you find no constants in the docs, you can still get the numeric value: Select the value in the GUI dropdown where it is used. Then drag the name label of the parameter into the console and press return. Python should then give you the current value of the parameter (sadly, not the name of the constant as Python has no information about these constants).

@del said in OBJ Export Options:

objExport[c4d.OBJEXPORTOPTIONS_EXPORT_UVS] = 1

Why 1? A quick look at the numeric value of the five options shows that they are between 4092 and 4096; none of them is 1. And you should use the profferred "constants" anyway, so it would be

objExport[c4d.OBJEXPORTOPTIONS_EXPORT_UVS] = c4d.OBJEXPORTOPTIONS_UV_ORIGINAL

etc.

You could use a Stage object and link the desired camera?
Stage[c4d.STAGEOBJECT_CLINK] = ...

@m_magalhaes said in What's the state of Ngons in Python?:

About the bugs on the forum, we have introduce few month ago new tags "Bug report" and "Bug Fixed". We are also adding some tag in our bug database to retrieve faster the post on the forum. I know it's not perfect and sometimes we may forgot to add this tag on the first post of the thread. But it's better than nothing.

Yeah, I'll try to use that in the future although it probably won't affect existing threads (a lot of valuable knowledge still resides in the "old forum" parts).

@Cairyn said in What's the state of Ngons in Python?:

Anyway, I don't think this issue is of huge interest as you said there's a replacement in the new kernel already, which will probably come with a diferent tesselation algorithm, so I present it here as a curiosity.

Don't get me wrong, all modeling command have been migrated to the new modeling kernel. If you are using SendModelingCommand, it will use the new kernel.
So what you see now in S22 and R23 (ok you will see in R23) IS the new kernel. There will be no better tesselation.
I consider this as a bug.

As a Perpetual user, I'm still on R21 (as tagged) so is this also the new kernel? AFAIK the new kernel has been working behind the API for a while now, being gradually introduced into the functionality, so it's possible that this bug still persists.

I can't test it on a demo of S22 for you, as the current licensing does not allow me to install one.

The new modeling kernel isn't exposed yet. But it is used. I understand, it's a bit confusing. We are moving Cinema4D to the new core. But as long as some part of Cinema4D are using the old system (object manager for exemple), the new core need to "translate" that to the classic API. (...)
I hope it's clear.

Sure, I have a few decades of programming under the belt. It's just a bit difficult as non-Maxon developer to see the details. Seeing only the API (and therefore the user-side of the translation layer), I can't always tell what the underlying data model really is; what's stored as attribute, what's calculated on the fly, what's internally cached for fast access, what's abstracted and what's plainly stored... I may make wrong assumptions on the internal workings.

this look like a valid ngon but i will ask :)

It probably is valid - I don't see a reason why it should be forbidden. I just notice that the tesselation algorithm tends to avoid such "inner polygons". That may not be intentional (based on a rule) though, but just a consequence of how the algorithm works.

Thanks again,
-- Cairyn --

@m_magalhaes Thanks again. I really should look into the C++ New Maxon API documentation, but I find it hard to get access to it. I am under the impression that the Maxon API does not really cover all aspects of the Classic API yet, and we still have to use BaseDocument, BaseObject etc for access. Which means that I cannot see the Ngons of the new kernel exposed (?)

Just two remarks:

Corollary: Any two polygons in an Ngon must transitively share an edge
Not correct. The polygons are an arbitrary valid tessellation of the polygon, and 2 polygons of that tessellation must not necessarily share an edge. There are however always two polygon that will share an internal edge.

I need to work on my wording, the "transitively sharing" was apparently not a wise choice (see above) . What I meant was: a polygon must be connected to the rest of the Ngon by a shared edge; all polygons share at least one edge with another polygon within the Ngon. It's only a corollary though from the previous two statements.

A polygon of an Ngon may have only inner Ngon edges (but its points still must be border points)
Not correct. Some polygons of the tessellation of an Ngon must make up the border edges and the hole edges of the Ngon and those are not inner ngon edges. All points must be part of the outline or a hole (no inner points) is Correct

I fell for a Germanism here in the usage of "may"; what I was trying to say was "can possibly". The situation I thought of was the following:

The innermost polygon (central triangle) contains only inner edges of the Ngon; it has no outer edges. I was actually surprised that this is possible since the tesselation algorithm seems to avoid such situations. This is not a C++ coded construct though; I only used onboard tools. It took me quite a few knife cuts and Melt calls before the tesselation finally came up with this.

@m_magalhaes Thank you for the answers!

Q1: ok, so the C++ functions are close to deprecation too... I thought these were already using the new kernel, but when looking at the timeframe, I notice that the Ngons have been around for a while...

Q2: I don't know, this is information found on a thread here, stating that the function is broken and will be fixed. I was unable to find a similar statement that it actually has been fixed. The corresponding thread peters out without saying so.
This is a general issue; I often browse old posts where something or the other doesn't work but I can't find information on the fix (if there even was a fix). Naturally, I understand that it's impossible to follow up on all old threads with fix information, but I wished there was a searchable list with all the fixes (that are announced with a release anyway, but often lacking the precise information) where I could look up what function was fixed when. Or a list of known errors, so any problems will not come as a surprise.
I assume this special error has already been fixed as I can't provoke a problem either today, but it's guesswork.

The file: ok, here's what I do:

I start with an octagon

There I delete some polys to create holes, and then I melt the whole object into one Ngon.

Note that the tesselation is pretty confusing even in parts of the octagon where the original polys would have made a perfectly legal tesselation of the Ngon, but that's another thing.

Now I cut an edge between two holes:

You can already see that this is going wrong... Looking at the result (highlighting the Ngon) I see that the hole is gone and actually the tesselation has created coincident polygons on top of each other:

The marked point in the following screenshot is the end of... well, it's partly an inner edge and partly an outer edge that ends in a... somewhat inner point.

It's hard to describe because the result is not even a proper manifold any more; when I lift the two edge points it becomes visible:

The foot edge of that polygon (opposite the two selected points, inner edge) is actually used by three polygons.
This is still all just one single Ngon (and it doesn't lead to crashes even inside of an SDS).
The behavior is easily repeatable.

Anyway, I don't think this issue is of huge interest as you said there's a replacement in the new kernel already, which will probably come with a diferent tesselation algorithm, so I present it here as a curiosity.

@zipit Yes, it's heavy lifting. Ngons are fairly nasty as far as side conditions are concerned. I must admit, I never did anything with them on the C++ side. But nevertheless I am surprised that they are practically missing from the Python API, with the exception of a few read-only functions.

The corollary is correct - it says "transitively share", so if you have polygons 1 and 2 sharing an edge, and 2 and 3 sharing an edge, then 1 and 3 are sharing an edge via 2. Okay, "share" may not be proper terminology, I could invent a new relationship operator, but people are already complaining about my overlong posts, so I try to suppress my inner mathematician

Hello again, as Ngons seem to pop up once again in the questions, I'm doing some investigations on them, and... well, they are still not very Python friendly.

Question 1: Is anybody currently working on expanding the Ngon handling in the Python API? (Status August 2020, comparing the newest Python and C++ documentation) Python is missing the classes Ngon and NgonBase and the struct NgonNeighbor. The PolygonObject does not have the functions GetNgonBase and GetAndBuildNgon. The modeling interface is missing AddNgon, SetNgon, FindNgon, GetNgon, NewNgon, and more. In total, that means Ngons cannot be created in Python (sure, we can use SendModelingCommand to send a Melt command, but that is not practical and only feasible at all in certain threading situations.)

This seems to be the case since a long time, and I wonder if the Python API will ever be amended to enable Ngon generation, or whether that's not even planned (as Ngon handling is fairly complicated and may not be suitable for the targeted Python audience)

(Edit: I am aware that there are functions in the PolygonObject that allow inferring the Ngons - returning the relationship lists between Ngons and polygons. But these are read-only: GetPolygonTranslationMap() and GetNGonTranslationMap().)

Question 2: Browsing the PluginCafé history, I found the mention that GetPolygonTranslationMap() is broken (2017). Is that still the case? It was also mentioned that the error is known and it's being worked on, but in lack of a complete error history I can't find a confirmation that it has been fixed. The thread ends shortly after without mentioning the issue again.

Question 3: Is there any documentation on permitted Ngon constructs? An Ngon is ultimately just a collection of polygons, but not every arbitrary collection of polygons can be an Ngon. This is normally ensured by C4D functions that generate the Ngons. But if we could create Ngons ourselves (let's pretend we have the needed C++ functionality), what are the rules? From the behavior of the Melt command, I can only infer:

• Disjunct polygons cannot make an Ngon
• Polygons that meet only in a point cannot make an Ngon
• Corollary: Any two polygons in an Ngon must transitively share an edge
• All points of an Ngon are border points. An Ngon cannot contain "inner" points (points that are only part of "inner" Ngon edges).
• An Ngon may not have edges that "cut into" the Ngon and end on an isolated point (an edge that is technically a border edge but neighbors only Ngon polygons)
• Ngons can contain holes, even multiple ones
• Ngons can be non-planar and have concave borders
• A polygon of an Ngon may have only inner Ngon edges (but its points still must be border points)

Also:

Melt may completely change the polygon selection and create triangles and poles with inner Ngon edges even if the original polygon selection in my opinion would have made a perfectly valid Ngon. -- I am fairly sure that this is just a weakness of the algorithm but I cannot be totally sure that there are more rules behind it that I simply don't know.

By cutting a line between two holes in an Ngon, I was able to create an Ngon that is invalid - it's not an open manifold, and it contains an edge that cuts into the Ngon. Apparently a bug, since the algorithm also closed one of the holes. Just for fun:
20200823__02__NgonInvalid.c4d

yupyup, BaseSelect has no connection to the original object it actually selects from, not even in the cases where you get a pointer to the BaseSelect returned and change the selection directly through it.

That's why we need the max parameter for SelectAll and ToggleAll -- the BaseSelect doesn't know what "all" even is. (Not GetLastElement()!) For GetRange() though, that reasoning does not apply.

Now let's see whether I can crash C4D with inconsistent edge selections...