Man this saved me so much time too. Thank you.

First of all, you should open new topics for new questions, as one otherwise tends to derail old topics, which makes it hard to for others to follow things later. I forked your topic. And I also do not quite understand what your question is. GetClosestMeshPrimitive returns you the primitive type via primInfo. When you only want to get the closest point on a mesh, I would build a KD-Tree for its vertices. You then get the closest vertex and its index for your point p. Then you orthogonally project p onto the polygons attached to that vertex (via cinema:: Neighbor). Then you chose the closest point. We have this Python example for KDTree and I also used Neighbor there. Building a KD-tree or just brute forcing it depends a bit on how often you want to do it. For just a handful of points, brute forcing it is usually faster. I am sure you can also do this with DistanceQueryInterface and the uvw coordinate returned in the PrimitiveInformation, but all that extra work where you have to deal with all the primitive types seems like more work than it is worth. And when you want to do this in a generator (by the looks of your screens), using a manual KDTree approach will make it easier to parallelize it effectively and make it go zoom zoom instead of computing all that extra data. Cheers, Ferdinand

Thank you all for your answers. Will test this.

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 Question We have noted your feedback and we are aware of some of the shortcomings of the current API. Subtool and folder management are high on the list of the use cases we plan to cover in a future API update. At the moment though, we don't have a set date for releasing a new version of the API. Please, let us know if you identify more areas of improvement. Regards, Davide

Thank you @ferdinand for looking into this, as well as bumping the request to the RS developers. Any update on this would be appreciated! Thanks.

Hey, yes it is. The trick is c4d.LV_CHECKBOX_HIDE, the relevant bits happen in GetDropDownMenu. Cheers, Ferdinand I removed the command, you can directly run this in the script manager: import c4d PLUGIN_ID = 12345678 PLUGIN_NAME = "ListView Dropdown Prototype" ID_TREE_VIEW = 1000 ID_FILE_NAME = 1001 ID_IMPORT_OPTION = 1002 ID_IMPORT_OPTION_DEFAULT = 1100 ID_IMPORT_OPTION_HIGH = 1101 ID_IMPORT_OPTION_MEDIUM = 1102 ID_IMPORT_OPTION_LOW = 1103 dummyfile_list = ["hud.stp", "material_reference.wrl", "front_axle.stp", "body.wrl", "wheel_variant.stp"] class DummyFile: def __init__(self, file_name, import_option="Default"): self.file_name = file_name self.import_option = import_option class DummyFileListView(c4d.gui.TreeViewFunctions): def __init__(self, dialog): self.dialog = dialog self.files = [DummyFile(file_name) for file_name in dummyfile_list] def GetFirst(self, root, userdata): return self.files[0] if self.files else None def GetNext(self, root, userdata, dummy_file): current_index = self.files.index(dummy_file) next_index = current_index + 1 return self.files[next_index] if next_index < len(self.files) else None def GetDown(self, root, userdata, dummy_file): return None def GetId(self, root, userdata, dummy_file): return id(dummy_file) def GetName(self, root, userdata, dummy_file): return dummy_file.file_name def IsSelected(self, root, userdata, dummy_file): return False def GetColumnWidth(self, root, userdata, dummy_file, column_id, area): if column_id == ID_FILE_NAME: return area.DrawGetTextWidth(dummy_file.file_name) + 24 if column_id == ID_IMPORT_OPTION: return 120 return 96 def GetDropDownMenu(self, root, userdata, dummy_file, column_id, menu_info): if column_id != ID_IMPORT_OPTION: menu_info["state"] = c4d.LV_CHECKBOX_HIDE return if not dummy_file.file_name.lower().endswith(".stp"): menu_info["state"] = c4d.LV_CHECKBOX_HIDE return options = { ID_IMPORT_OPTION_DEFAULT: "Default", ID_IMPORT_OPTION_HIGH: "High", ID_IMPORT_OPTION_MEDIUM: "Medium", ID_IMPORT_OPTION_LOW: "Low", } for option_id, label in options.items(): menu_info["menu"].SetString(option_id, label) menu_info["entry"] = next( option_id for option_id, label in options.items() if label == dummy_file.import_option ) menu_info["state"] = c4d.LV_CHECKBOX_ENABLED def SetDropDownMenu(self, root, userdata, dummy_file, column_id, entry): if column_id != ID_IMPORT_OPTION: return #this is logical but does not do the trick .... if not dummy_file.file_name.lower().endswith(".stp"): return options = { ID_IMPORT_OPTION_DEFAULT: "Default", ID_IMPORT_OPTION_HIGH: "High", ID_IMPORT_OPTION_MEDIUM: "Medium", ID_IMPORT_OPTION_LOW: "Low", } dummy_file.import_option = options.get(entry, dummy_file.import_option) self.dialog.tree_view.Refresh() class ListViewDropdownDialog(c4d.gui.GeDialog): def __init__(self): self.tree_view = None self.file_list_view = DummyFileListView(self) def CreateLayout(self): self.SetTitle(PLUGIN_NAME) tree_view_settings = c4d.BaseContainer() tree_view_settings.SetBool(c4d.TREEVIEW_BORDER, c4d.BORDER_THIN_IN) tree_view_settings.SetBool(c4d.TREEVIEW_HAS_HEADER, True) tree_view_settings.SetBool(c4d.TREEVIEW_HIDE_LINES, True) tree_view_settings.SetBool(c4d.TREEVIEW_RESIZE_HEADER, True) tree_view_settings.SetBool(c4d.TREEVIEW_FIXED_LAYOUT, True) tree_view_settings.SetBool(c4d.TREEVIEW_ALTERNATE_BG, True) if c4d.GetC4DVersion() >= 24000: tree_view_settings.SetInt32(c4d.TREEVIEW_VERTICAL_SPACE, 4) self.tree_view = self.AddCustomGui(ID_TREE_VIEW, c4d.CUSTOMGUI_TREEVIEW, "", c4d.BFH_SCALEFIT | c4d.BFV_SCALEFIT, 500, 220, tree_view_settings, ) if not self.tree_view: return False layout = c4d.BaseContainer() layout.SetLong(ID_FILE_NAME, c4d.LV_TREE) layout.SetLong(ID_IMPORT_OPTION, c4d.LV_DROPDOWN) self.tree_view.SetLayout(2, layout) self.tree_view.SetHeaderText(ID_FILE_NAME, "Dummy file") self.tree_view.SetHeaderText(ID_IMPORT_OPTION, "STP import option") self.tree_view.SetRoot(self.tree_view, self.file_list_view, None) return True def InitValues(self): self.tree_view.Refresh() return True if __name__ == "__main__": dialog = ListViewDropdownDialog() dialog.Open(c4d.DLG_TYPE_MODAL, 0, -1, -1, 500, 220)

You likely have to call UpdateOcioColorSpaces, just follow the example. There is btw no guarantee at all that DOCUMENT_COLOR_MANAGEMENT entails a render space of ACEScg. That is just the default, the user could have changed that. I am also not sure what all that RDATA_IMAGECOLORPROFILE code is meant to do. It depends a bit on what your plugin does and what self.IsForceLinear is meant to express. Only so much: An OCIO document does not necessarily entail a bitmap with a non-linear color profile, and OCIO also does not mean that the bitmap has to be 32bit. You are however missing UNDOTYPE_PRIVATE_DOCUMENTDATA undo management for setting the color management.

@ferdinand Okay, I will handle the plugins and files at an appropriate time.Thanks reply

@ferdinand Thanks for your detailed explanation. Although the precision conversion leading to value changes is not an error, it is indeed not what we want in terms of the results. For example, when dealing with the weight of some points, using SetWeightMap() will update the weights of other points, resulting in numerical changes. Only using SetWeight() can at least ensure that the weights of unoperated points do not undergo numerical changes (but using SetWeight() must tolerate the print warnings outputted by the console)

Hi, @ferdinand and @Anlv this is most awesome! All way beyond my capablities so thanks a lot for the scripts!

Hey @Kantronin, you might want to look at geometry_polgyon_edges_2024.0.py, it should answer all your questions. The TLDR is: full-edge maps as you hint at in your posting do exist in Cinema via helper functions, but they are often also not very useful. Internally, Cinema is operating as any other DCC application with the concept of what is often called a "half-edge" data structure. So, when you have the two polygons A and B: a---b---e | A | B | d---c---f Which share an edge over the vertices b and c, this is actually two edges and not one, due to how normals work. For both polygons to have a normal facing in the same direction, they must have opposite winding orders, which means that the edge b-c is actually two edges: b->c and c->b. So, A could for example index the edge as bc, and B as cb. The example goes into more detail with this. Cheers, Ferdinand

@ferdinand Thanks for your detailed explanation and the implementation of the sorting function. It's very helpful！

Thanks Anlv It looks like its adding the emitter into a null is what's causing it. Fixed with deferred CallCommand(1062577) (no sub-id (1067510) silently no-ops). Emitter fields greys if the emitter/group are parented under the setup null or generator. Sibling placement below plugin object + rename works fine.

There seems to be some solution, please stay tuned until the RS team has sorted out things. I will then update this topic.

What I meant was to use the Cineware Unreal bindings, but I am not sure if they support it. Going the export route is a big backwards when Cinema has specific bindings. https://www.maxon.net/en/cineware I will give the Unreal dev a bump when I see him again.

Yes I wanted submenu with Icon, thanks for Up to Date clarification.

This is not common knowledge, otherwise I would have spotted that earlier. So, you are not really expected to know this as a third party dev. You can look at the geometry_caches_s26.py example and there at this line, under [2] I mention that the cache of that object is muted. But that is of course only very indirect information and not enough to deduce this. I think we also talked about it a couple of times on the forum. The flag BIT_CONTROLOBJECT is set on input objects of generators, e.g., the to be extruded spline of an Extrude object, the profile and rail spine of a Loft object, the to be cloned cube and sphere objects of a MoGraph cloner, etc. As shown in the caching example, Cinema will mute the caches of input objects. To be very formal, they are actually built but then again deleted. BIT_CONTROLOBJECT marks such input objects. Your light in that scene should not have that flag, as it is not the input for some generator. But it somehow got it anyway, there is probably somewhere a bug. For normal scene evaluation that bug is also not really a problem (because as you saw from your own test, the light still converted correctly when you inserted it on its own outside of caches). The problems start when that irregularly as BIT_CONTROLOBJECT marked object is part of a cache. 'Make Editable' then incorrectly collapses the cache. Not only does it not stop at nested generators which are incorrectly marked like this, it also seems to apply the cache muting logic for input objects (resulting in the empty null object instead of the content of the cache of the collapsed generator). I already told the relevant devs that I consider this borderline buggy but they do not seem very inclined to do anything about this. What is effectively missing somewhere in cache resolvement is the evaluation if the flag BIT_CONTROLOBJECT 'makes sense on an object'. That is of not so easy to do, as generator - input object relations can be quite complex in Cinema. Which is probably also why the modelling team does not want to touch this. Cheers, Ferdinand

This is how I’ve implemented it at the moment, although users can’t drag and drop selection tags in the same way as with C4D’s built-in generator. Hope there are plans to expose the proxy tags. Thanks for tour time!

@ferdinand Yes, thanks, that indirect answer is enough for me. I was mainly wondering whether a check performed on both the client and the server is robust enough, or if it could be bypassed using Python, for instance. I’m well aware that it can be cracked somehow. I’m also already using ExportLicenses() for my node-locking system in combination. Thanks a lot for your help.