Hey @lionlion44,

Thank you for reaching out to us. I doubt that this will not work in Python, it is just that we have not documented the symbols there yet. But you can find them in the C++ docs:

6e23eada-2198-4c34-84bf-a576bbdd0ef9-image.png

I.e., it will be c4d.FORMAT_USDIMPORT and c4d.FORMAT_USDEXPORT.

Cheers,
Ferdinand

@ferdinand Thank you for your in-depth analysis. It would have taken me way too long to figure this out lol, especially finding "CUSTOMDATA_BLEND_LIST". The first example seems to work for me, but like you said, it may not be reliable. The Python node example also works great. Again, thank you for your time.

Hey you need to react to MSG_GETCUSTOM_NAME_ADDITION and return a dict with the expected string with the "res" key.

You need to register your object with c4d.OBJECT_CUSTOM_NAME_ADDITION to have the additional name displayed in the Object Manager.

Cheers,
Maxime.

Thank you both!

@m_adam Thank you so much for the help, that works perfectly and thank you for showing me both methods, that's very helpful and appreciated!

Thank you, Maxim.
No further testing is needed—this works very well.
I’m calling it from the ToolData::MouseInput() callback at the end, which is sufficient. The panel updates nicely after the mouse event finishes (on mouse up).

SendCoreMessage(COREMSG_CINEMA, BaseContainer(COREMSG_CINEMA_FORCE_AM_UPDATE));
GeUpdateUI();

You can close this thread.
Thanks!
V.

I'm not sure I understand you correctly, you do not have to use QuickTabRadio bar with resource, you just retrieve the int value of the parameter, in the case of the previous example I share with a GetInt32(c4d.MGCLONER_VOLUMEINSTANCES_MODE).

If you can provide a code example of what is blocking you that would be nice.
You can find a non-exhaustive list of type of control available in *res file within the C++ documentation in Description Resource.

Cheers,
Maxime.

Thank you for the C++ code—it's been very helpful!
Cheers！

Hey @Pheolix,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment. Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support. Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions.

About your First Question

Your code looks generally good, especially for someone who is starting out with the API you did really well. With that being said, I do not really understand what you want to do:

... plugin that maps and arranges textures onto a pixel grid. The goal is to make it easier to create voxel-style or Minecraft-like models by linking real-world units (e.g., centimeters) to pixels. (for example, 1 pixel = 6.25 cm)

A few pointers:

A CommandData plugin is the perfect choice when you want to manipulate the scene without any restrictions and are fine with always having to press a button run your logic. Scene element plugins, e.g., objects, tags, etc. on the other hand will carry out their logic on their own when a scene update is invoked. But they come with the restriction that their major payload functions (ObjectData::Execucte, ObjectData::GetVirtualObjects, TagData::Execute, etc.) run in their own threads (so that scene execution is parallelized) and therefore are subject to threading restrictions (I am aware that you are on C++, but the Python docs are better on this subject). So, for example, in a TagData::Execute you would not be allowed to allocate a new UVW tag on the object that is also hosting your plugin tag. But you could implement a button in the description of the tag, which when clicked cerates your setup (because TagData::Message runs on the main thread and you therefore are there allowed to add and remove scene data). With TagData:Execute you could then continuously update the UVW tag you are targeting on each scene update (changing parameter values of other scene elements is fine when tags are executed). This workflow is not necessarily better than a command, I am just showing you an option. Commands are also easier to implement for beginners than a scene element. When you talk about units, you should be aware that both the object and texture coordinate system are unitless. What you see in edit fields, is just smoke and mirrors. We recently talked here about this subject. You did get the major gist of our error handling but what you do with maxon::Failed is not quite correct. It is meant to test the return value of a Result<T> for having returned an error instance instead of T. When you want to indicate an error, you must return an error, e.g.,: // Not correct. if (!doc || !selectedObject || !bitmap || !foundTag) return maxon::FAILED;T // This is how one indicates that a function failed because something was a nullptr. if (!doc || !selectedObject || !bitmap || !foundTag) return maxon::NullptrError(MAXON_SOURCE_LOCATION, "Could not get hold of scene data."_s); // For a function which is of type Result<void>, its also totally fine to do this on an error. void functions // can fail successfully, it is up to you to decide if an error is critical enough to halt execution of if you just // want it to silently terminate. if (!doc || !selectedObject || !bitmap || !foundTag) return maxon::OK; // we are okay with failing here.

For details see Error handling and Error Types

Cheers,
Ferdinand

Hello @ECHekman,

Thanks for providing the information that the init function should not modify the scene graph. Ill take this into account in the future.

It is not only NodeData::Init but the majority of NodeData methods and the methods of derived classes that cannot modify the scene graph of a loaded document, as for example the scene graph they are attached to. The reason is that such methods, as for example NodeData::Init, TagData:Execute, ObjectData::GetVirtualObjects, and many more, run in their own threads to parallelize scene execution. Modifying the scene graph of a loaded document from a non-main-thread (i.e., parallel) context can lead to race conditions and access violations and are therefore strictly forbidden. Forbidden are primarily allocations and deallocations, parameter get/set access is allowed (as long as it does not allocate or deallocate a pointed object) but also discouraged outside of TagData::Execute. For details, see Cinema 4D Threads Manual.

I went through that example you linked, but I' m a bit unclear why it is necessary to manually create the handling of a custom and parallel nodegraph branch when plugin GeListNodes are already graphs themselves?

I am not quite sure how you mean 'parallel', but a GeListNode implements both hierarchal (i.e., tree) relations with InsertUnder, GetUp, GetDown, GetNext etc. and arbitrary (i.e., graph) relations with GetBranchInfo. The hierarchy of a node type, e.g., Obase - a BaseObject or Tmytag - your tag class, are always meant to be of the same type and follow the conventions of their base class. Tags are not meant to have children. You must implement your own branch to declare your own non-hierarchical relation between your plugin tag and your basic node.

⚠ The workaround Maxime suggested, just implementing NodeData::CopyTo is unfortunately not valid.

First of all, you must always implement all three serialization functions Read, Write, and CopyTo, you can never only implement only one of them.

But storing nodes irregularly in this manner can lead to access violations as Cinema 4D is then not aware that this quasi-branch exists and might try to execute multiple things at once (via NodeData::GetAccessedObjects), leading to read/write access violations. Moreover, I am fairly sure that this might lead to event or call starvation when Cinema finds there such a dangling BaseList2D (NodeData) instance under your BaseTag (TagData). Or even worse, it will ignore completely it in some contexts, because tags are not supposed to have children.

You must implement a branch in your case, I would recommend following the SDK example as it is slightly cleaner than the forum preview Maxime linked to.

Cheers,
Ferdinand

Hey Jacob,

Thank you for the added data. First of all, I have invited you to the forum to end this middle man communication, which is a bit odd.

The pyz file is part of python ...

I am aware of what pyz is, I just pointed this out because I of course looked inside your package and found all the py_armor obfuscated code and the injected binaries in there. So, I pointed out that this is bit more than just "packaged in a pyz file for ease of distribution [...]" as Lasse/you put it, the goal is here clearly obfuscation. Which is also relevant for support, as it limits what you and I can see (without getting hacky).

My finding with the 10mb file freeze comes from my trial and error ... mean[t] when you run a script from Extensions -> User Scripts.

Your code also freezes when you load it as a Script Manager script. That is what I did with the last package from Lasse, and now also yours. The code in your script is again wrong, which is why it won't freeze until you fix it. This is the code I found:

2bd4290e-78b2-43d4-936d-1e2a7eaf366b-image.png

And I fixed it then to this. When I ran it then, Cinema 4D froze for two minutes or so, after that it opened a myriad of dialogs to then terminate into two crash dialogs (it was pure luck that I let it run for so long, Lasses previous version might have acted similar, but there I killed the C4D process, as soon as I saw the 'beach ball of death' cursor on MacOS).

69fcb5da-ac49-477e-8f70-9daeb1daa1aa-image.png

⚠ Please read my answer below carefully, as I already pointed out most of this in my previous posting.

I would STRONGLY suggest debugging this without obfuscation. Maxon also cannot debug larger sections of code or test further packages for you. I understand that obfuscation might not be your choice, but it will make your life harder in debugging this, as you always fly blind. We of course still will provide support, but you have to provide more than "it does not work/crashes/freezes, please help us", especially when this is not code tied to our APIs. Attach a debugger from the Script Manager and see why your code crashes/freezes (see link in last posting when unsure how to do this). But you need an un-obfuscated code base for this to make any sense. Defer your loading to a later point, e.g., C4DPL_PROGRAM_STARTED, when you have issues in the direct plugin registration context. In that case you would always register your plugin, but then only execute it when the your own license check succeeded. But you absolutely cannot ship a plugin which freezes Cinema 4D for multiple minutes on startup or when invoking your plugin because your licensing takes so long. When we see this in the wild, we will have to blacklist your plugin IDs, as this damages the brand Cinema 4D. Please use threading then to not block the main thread with your long running code. What I did not notice before is that you apparently try to open multiple dialogs (for me it opened multiple dialogs when I ran the script). The GUI and many other systems are not yet available when Cinema 4D is still booting, e.g., in the splash screen. You can expect all systems to be up and running when C4DPL_STARTACTIVITY is emitted, but it is better to wait for C4DPL_PROGRAM_STARTED for long running tasks (i.e., the two events I tested in my previous posting). Please also keep in mind that Cinema 4D has its own anti-piracy measures. Python plugins are sort of special in that they work slightly different than native C++ plugin modules (the Python C++ module shipped by Maxon sort of acts as a surrogate for Python plugins in the module registration phase). But Cinema 4D won't allow plugin threads to start their own processes at this point (which you might be trying to do with your injected binaries), and threading should also be avoided at this point, as the job system of Cinema 4D might be still booting. What you are meant to do in PluginStart (or the __main__ context of a pyp file), is register your plugins. You can run some quick logic there, but you are certainly not meant to start communicating with servers and opening GUIs there. You can read here a bit more about this from a C++ system perspective. I would recommend to do your license check in the background in its own thread once C4DPL_PROGRAM_STARTED has been emitted (so that you can also open dialogs to signal errors). An alternative would be to do it when the user clicks the button of your command. But you should also here put it into its own thread, so that it does not block everything else.

Cheers,
Ferdinand

Hi @ferdinand,
Apologies for the lack of context earlier. I didn’t mean that it returns null, but rather that it returns an object inside a null container. When I try to modify the scale of the resulting object, this behavior persists. I’ve noticed a similar pattern when working with Python generators.

import c4d from c4d import utils def Cube(): obj = c4d.PolygonObject(8, 6) obj.SetPoint(0, c4d.Vector(-100.0,-100.0,-100.0)) obj.SetPoint(1, c4d.Vector(-100.0,100.0,-100.0)) obj.SetPoint(2, c4d.Vector(100.0,-100.0,-100.0)) obj.SetPoint(3, c4d.Vector(100.0,100.0,-100.0)) obj.SetPoint(4, c4d.Vector(100.0,-100.0,100.0)) obj.SetPoint(5, c4d.Vector(100.0,100.0,100.0)) obj.SetPoint(6, c4d.Vector(-100.0,-100.0,100.0)) obj.SetPoint(7, c4d.Vector(-100.0,100.0,100.0)) polygon1 = c4d.CPolygon( 3,2,0,1)#front polygon2 = c4d.CPolygon( 5,4,2,3)#left polygon3 = c4d.CPolygon( 7,6,4,5)#back polygon4 = c4d.CPolygon( 1,0,6,7)#right polygon5 = c4d.CPolygon( 2,4,6,0)#down polygon6 = c4d.CPolygon( 5,3,1,7)#up obj.SetPolygon(0, polygon1) obj.SetPolygon(1, polygon2) obj.SetPolygon(2, polygon3) obj.SetPolygon(3, polygon4) obj.SetPolygon(4, polygon5) obj.SetPolygon(5, polygon6) polygon_count = obj.GetPolygonCount() uvw_tag = obj.MakeVariableTag(c4d.Tuvw,polygon_count) for i in range(uvw_tag.GetDataCount()): uvwdict = uvw_tag.GetSlow(i) p1 = c4d.Vector(1,0,0) p2 = c4d.Vector(1,1,0) p3 = c4d.Vector(0,1,0) p4 = c4d.Vector(0,0,0) uvw_tag.SetSlow(i, p1, p2, p3, p4) obj.SetPhong(True, 1, utils.Rad(40.0)) obj.Message(c4d.MSG_UPDATE) return obj def main(): obj = Cube() scale = 2 obj[c4d.ID_BASEOBJECT_REL_SCALE,c4d.VECTOR_X] = scale obj[c4d.ID_BASEOBJECT_REL_SCALE,c4d.VECTOR_Y] = scale obj[c4d.ID_BASEOBJECT_REL_SCALE,c4d.VECTOR_Z] = scale return obj

I’d like to understand why this behavior occurs, and— as I mentioned earlier— if there's a way to define custom behavior for CTSO within a plugin. Once again, sorry for the confusion caused by my previous message.

Just to clarify, modifying the polygon's scale by adjusting its vertices is not an option, since I want the polygon to be generated with those specific attributes already modified.

Thanks for your support,
James H.