Posts made by Cairyn

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...

Speaking of PolygonObject.GetNGonTranslationMap, the Python description seems to be wrong (copied from the C++ docs?). The doc says

ngoncnt (int) – The number of N-gons. Pass the length of the list returned by GetPolygonTranslationMap(), not the value given by GetNgonCount().

but the number needed here is not the length of the list (second return value), but the first return value of GetPolygonTranslationMap.

For the return value, the doc explains

The number of polygons in N-gon i is stored in list[i][0].
Then the polygon indices are stored in list[i][j] where j goes from 1 to list[i][0].

but the number of polygons is not stored at all. The sublists are simply the polygon indices, and the number must be inferred with the len() function.

(Newest online docs, tested with R21)

@zipit said in What is the max parameter in BaseSelect.GetRange() really for?:

About your error, are sure that actually the method is raising the error and not your surrounding code with an unpacking or indexing operation for example? When the return value is None, that would give you exactly that error. E.g. this will fail when the method fails, i.e. returns None:

a, b = selection.GetRange(*data)

Aha, good thinking! Yes, that's exactly the error.

The doc for the parameter doesn't say that the function completely fails when the max condition is not met - it just states The method makes sure they are < max.
That of course also answers my question what happens when a and b both are < max. It makes the existence of the parameter even more mysterious, but it explains why I get this error.

I definitely need to be more careful with return value checking... thanks!

@PluginStudent But the indices in the segment in the BaseSelect are automatically valid if the BaseSelect was built by a valid source. The only way to get invalid values would be to apply the same BaseSelect to a different object with less polys/points, and in that case the function GetRange() is of lower priority - you'd get out of range errors much earlier.

If you really have an arbitrary BaseSelect to store indices from a list, and the BaseSelect contains indices that are not in the list at all, then your code is buggy, and limiting the output of GetRange() would be just covering up that bug.

It's confusing. Maybe it's just a relic from some older code, grandfathered into the current API.

As the headline says...BaseSelect.GetRange() returns the min and max values for a segment in a selection. But it has a second parameter (besides the segment), called max.

Now, max is not needed from a structural point of view. The selection contains a known number of segments, which contain one tuple each. Other than e.g. BaseSelect.SelectAll(), where we actually need to pass a max value because the BaseSelect does not know the total number of elements that may possibly selected, GetRange() does not deal with unknowns.

The documentation says about this parameter:

max (int) –
The maximum value for the returned elements numbers.
Usually pass PolygonObject.GetPolygonCount() or PointObject.GetPointCount() or the edge count of the object.
The method makes sure they are < max.

I would interpret that as assurance that any value we get returned is smaller than max. So if there is a segment (1,5) and max = 3, then we'd get (1,3) back. (I can't for the life of me think of a reason why I would want that, but hey.)

That is, however, not what I really get. If I use a value for max that is smaller than the value GetRange tries to return, I receive TypeError: 'NoneType' object is not iterable. If I use a ridiculous large value for max, no apparent effects happen at all, not even a perceivable increase in runtime.

So, I have a parameter that at best does nothing, and at worst throws an error. I don't know whether this is a bug (R21) or whether I just don't understand the function.

The C++ doc says about the same parameter:

The maximum value for a and b. Makes sure a and b are < maxElements. Pass LIMIT<Int32>::MAX for no additional checks.

That supports my understanding of the parameter, but does not explain why I get a TypeError instead.
(It also doesn't explain why a limit on the selection is so important that it justifies an additional parameter when the check could easily be done on the returned values. Or: what happens, if both returned limits of the segment are larger than max.)

btw, it would be nice if the Python docs also contained the additional info from the C++ doc:

The spans are always sorted (spans with higher index have higher numbers for a/b), also b is always >= a. 

@android Here's a thread for reference regarding the limitation of a Generator spline:
https://plugincafe.maxon.net/topic/12596/is-it-possible-to-get-a-spline-wrap-object-to-use-a-python-generated-spline

@John_Do said in Python, tool attributes and hotkeys:

@Cairyn
Sorry for the misunderstanding, in my mind hotkeys = shortcuts, I didn't want to make any particular distinction. What you described is also called Sticky Keys in some softwares.

Yeah, the nomenclature for keyboard shortcuts is unfortunately all over the place. I know Sticky Keys as the type of behaviour where you type a key and release it, but the key still registers as pressed, until it is pressed a second time. This is the case for e.g. Windows' "easy access" for qualifier keys. (No idea whether this is still called that; I'm on a German system.)

But sadly every system, every application, and every user uses the terms as they just come to mind, so it's fairly worthless now without an explanatio every time. I was just pointing out the "hotkey" as Cinema 4D actually uses this term in its API.

To answer your questions : I want to be able to modify tool settings / attributes while the tool is enabled AND in interactive mode. Since I don't want to bother with gazillions of shortcuts and multiple keyboards, it has to be context sensitive so I can use the same set of keys with many tools.

But a picture is worth a thousand words, so I made a little demo of what I want to achieve in C4D : Modal Bevel Shortcuts demo

I understand what you want to do... I suppose as long as you reserve the necessary keys for your scripts/tools, it's possible to get the effect. I was actually thinking along the lines "if you want these keys to work only when the tools are active, and have their original meaning if something else is active" which is a much more difficult goal - it would force you to remember the original function in some way, and jump there if your target tools are not active. I actually have no solution for that, as Cinema does not have an additional context sensitive layer for keyboard shortcuts that depends on tools. (I often wish for that.)

I might offer the functions to swap out the keyboard shortcuts dynamically, but you probably don't want that and have found these already anyway ;-)

• Is there is a way to gather all the commands in one file / script but output as many commands as shortcuts needed ? Right now I have one script per command, it's a bit clunky.
  I guess plugin and command registering is the answer ?

You can create one file that registers several command plugins. You need a separate ID from the PluginCafé for each, but it's easy to achieve. The plugin needs to go into the plugin directory then, naturally.

Doesn't look coarse to me, neither as script nor as generator

Generator:

import c4d

def main():
    obj = c4d.SplineObject(4, c4d.SPLINETYPE_BSPLINE)
    p1 = c4d.Vector(0.0, 0.0, 0.0)
    p2 = c4d.Vector(100.0, 0.0, 0.0)
    p3 = c4d.Vector(100.0, 100.0, 0.0)
    p4 = c4d.Vector(0.0, 100.0, 0.0)
    obj.SetAllPoints([p1, p2, p3, p4])
    obj[c4d.SPLINEOBJECT_INTERPOLATION] = 2 # here: uniform
    obj[c4d.SPLINEOBJECT_SUB] = 20 # number of subdiv points
    obj.Message (c4d.MSG_UPDATE)
    return obj

Did you use enough points? set the interpolation and subdivision? There is not much room for settings here...

Note that a Python generator cannot act as spline itself (see some other threads for that), even if it can contain a spline. There is currently no Python Spline Generator in C4D.

@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.

Hello;

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...)

(It just came to mind that you may not mean "hotkey" but "keyboard shortcut". A hotkey is a special kind of keyboard shortcut that takes effect while it is pressed, so it switches on when you press and keep pressing, and switches off when released. The hotkeys are the ones that require the PLUGINFLAG_COMMAND_HOTKEY flag. For other keyboard shortcuts that trigger an action on release only you can use a simple script where applicable and don't necessarily require a command plugin.)

I'm not quite sure what you are looking for... the code does change the settings in the tool, not just "the UI", provided you define the function tool() which the script log automatically does.
If you expect the default tool settings to change: no, that is not what the script does.
If you expect the script to trigger the tool (cause the tool to execute): no, the script only changes the settings, you still have to click Apply or New Transform.

To execute the Bevel tool, you can use SendModelingCommand instead of the stuff the Script Log recommends:

import c4d
from c4d import gui, utils

def main():
    doc.SetMode(c4d.Mpolygons)
    doc.StartUndo()
    doc.AddUndo(c4d.UNDOTYPE_CHANGE, op)
    settings = c4d.BaseContainer()      # Settings
    settings[c4d.MDATA_BEVEL_MASTER_MODE] = c4d.MDATA_BEVEL_MASTER_MODE_CHAMFER
    settings[c4d.MDATA_BEVEL_OFFSET_MODE] = c4d.MDATA_BEVEL_OFFSET_MODE_FIXED
    settings[c4d.MDATA_BEVEL_RADIUS]      = 10.0

    res = utils.SendModelingCommand(command = c4d.ID_XBEVELTOOL,
                                    list = [op],
                                    mode = c4d.MODELINGCOMMANDMODE_POLYGONSELECTION,
                                    bc = settings,
                                    doc = doc)
    doc.SetAction(c4d.ID_MODELING_MOVE)
    doc.EndUndo()
    c4d.EventAdd()

    if res is False:
        print "Something went wrong."
    elif res is True:
        print "Command successful."
    elif isinstance(res, list):
        print "Oops, you got new objects?"

# Execute main()
if __name__=='__main__':
    main()

Regarding the hotkeys: I have a hunch that you want to use C4D in a way that is not really supported. A keyboard shortcut triggers a script or a tool or a command - hotkeys are global and depend on the command behind it. You can make them context sensitive by checking the current tool in the called script, and then react accordingly, but that still requires that you bind that key to that command, not the other way round.

You may be able to catch key press events from the messaging system and evaluate them yourself, but that would require much programming experience and API knowledge, and you will probably break the shortcut system.

If you just want to define your own hotkeys, you will need to program a command plugin with the flag PLUGINFLAG_COMMAND_HOTKEY set. That's not context sensitive, again, you would have to program any context dependencies yourself. At least you wouldn't need to have a preferences plugin to assign them; any script or plugin can have its keyboard shortcut assigned on the Customize Command window.

Provided I even understand correctly what you want... if you could describe an actual usecase...?

---

Learn more about Python for C4D scripting:
https://www.patreon.com/cairyn

doc never changes in your code. The predefined variable doc refers to the active document at the beginning of the script, which I assume is the architect's model. Opening a new scene through LoadFile does not change doc so you are still getting the object list for your original document. Try using lowResDoc = c4d.documents.GetActiveDocument() to get the newly opened document.

Does your setup react to the global Level of Detail controls?
If not, could you use a local LOD object with differently subdivided children?