@ferdinand Thanks for reply. Perhaps not expressed clearly. For changing the axis of an object, it is not a problem. What I want to ask is whether the manual operation step of selecting the axis before the Move tool works can be implemented using a script.

Thanks you for your help

Hi Kent, the cast is safe. In the public API, NimbusInterface is an incomplete type. Only NimbusBaseInterface is defined there. But internally, NimbusInterface is derived from NimbusBaseInterface, therefore you can safely do the cast.

@ferdinand Thank you so much. He perfectly solved all my problems

Thank you very much for following up with this, @ferdinand. At the moment, we are fairly confident about the way of fixing this issue after all the above discussion. But I'll reach out with a bug report (even though I don't think this is C4D bug) for further information.

Hi @ArjenA , 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: Asking Questions. About your First Question Unfortunately we're not able to provide you with support on designing an architecture of your application, hence my answer here is very limited. Though, you're very welcome to ask more specific questions Let's call your setup with physical board game, hardware and corresponding software as "backend" and the C4D part as "frontend". Generally speaking, there's nothing preventing you from making these parts communicating with each other and it all highly depends on your project setup: programming languages, physical interfaces, frameworks, etc that you're going to use. You can start with saving your live data in a file on your disk filesystem and read it using Python API in cinema. Once you have a proof of concept you can start optimizing, for example, by implement a proper communication interface, for example, REST API or Websocket sound like good (but not the only!) candidates for this purpose. With that's said, I wish you luck with your project. Feel free to make new postings with singular and more specific questions. Cheers, Ilia

@ferdinand Thank you for replying!

@i_mazlov Thanks for your help. I using visual studio code as you suggested and am getting to grips with the Drag and Drop to assist with parameter getting and setting.

Hi @kimberlyhtown, 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: Asking Questions. About your First Question I suppose you're asking about the Attribute Manager history, which one can access by using the following arrows: [image: 1738944299742-bf4e829b-8ae1-4eae-a86b-c8dbc57c713d-image.png] Unfortunately, no. the Attribute Manager is a quite complex part of C4D (e.g. with multiple AM having each their own history), hence it is not transparently exposed to our public SDK and one's typically limited by the functionality listed in our C++ SDK the AOM part: Active Object Manager. Cheers, Ilia

@ferdinand Thank you for answering ,I 'll try it.

I can confirm that you were right (nothing unexpected there!) - this is the second time in a couple of weeks where casting has bit me in the behind. I guess I was too spoiled by C# and need to keep my head turned on in the future.. For anyone from the future reading this: The problem with the code above was READING the value, not WRITING it back to the object. That part was ok. Either passing on for instance op as a parameter or using Get() (if you're on the right object) to get at it is the right move. Thanks again!

Hello everyone, we have moved this topic to a mail discussion, when there are outcomes relevant for other developers, I will post them here. Cheers, Ferdinand

Thanks for your response. We found the issue. Turns out we had to delay load our dlls for earlier versions of the plugin R21 etc

Hello @Futurium, thank you for reaching out to us. It pains me a bit to say that, because you made so nicely sure that we have all resources, but your topic is out of scope of support, specifically the points: We provide code examples but we do not provide full solutions or design applications. We cannot debug your code for you and instead provide answers to specific problems. Sometimes we cut people some slack here but in your case this is just too much work. Some High-level Advice The Take system of Cinema 4D is one of its most liked features. What comes to users sometimes as a surprise, is the technical complexity of the Take System/API; one could also say that it has a bit the reputation of being overly difficult to deal with. While the API is manageable when you get used to it, I would really avoid trying to write a custom serialization and deserialization routine for take data, due to all that complexity. It is certainly possible to do, but at least I would be very hesitant to do that due to all that complexity wich must be met. In general, you can serialize and deserialize scene elements (nodes) with C4DAtom.Write/Read. Since takes are also of type C4DAtom, you could in theory also serialize/deserialize them like that. I added there the 'in theory' because we generally discourage third parties from using such low-level IO, as you can relatively easily brick your data like this by missing important internal dependencies and/or crash Cinema 4D like that. For takes this could mean that internal data is not copied/serialized properly or that one of the many (Base)links used in takes fails to reattach upon being loaded in another scene. I personally would try to use the Take Asset Presets to do what you want. Saving a preset is easy, just select it, and then call the command for it. Loading the take preset programmatically might be a bit trickier. Take assets were added after I wrote for S26 the Asset API documentation, and I never used them myself. I am not sure if you can load a take asset just with maxon.AssetManagerInterface.LoadAssets or if you have to get your hands dirty yourself with a more manual approach. Okay scratch that, I just tried out Take Assets and they probably do not do what you want to do (we might ourself have deemed this a too complex task to fully reattach takes in a new scene). In the end, doing it manually with JSON might indeed be the only option for what you want to do, but we cannot do that for you or debug your code for you. Cheers, Ferdinand

Hi Tomasz, Thanks for reaching out to us. First I'd like to note that according to our Support Procedures we cannot provide you with complete solutions: We provide code examples but we do not provide full solutions or design applications. We cannot debug your code for you and instead provide answers to specific problems. Regarding your question. In short, what you're trying to do here is not easily achievable (if possible at all). Although, you can manipulate Redshift AOVs as discussed in get the names of redshift multi passes AOV names from the render settings, I'm afraid there's no such functionality exposed for interacting the baking tool itself. This effectively means that you can simulate pressing the "Bake" button in the bakeset attributes using C4D API, but you cannot skip manual interaction in the bake tool. I'd suggest you double checking this on redshift forum as it would be the place with the most concentrated knowledge on this topic. Regarding your related questions. First, please make sure you're dedicating your threads to a singular question or topic as explained in How to ask questions: Singular Question: The initial posting of a support topic must contain a singular question. Do not ask ten things at once, that makes it extremely hard to answer topics. Break up your questions into multiple topics. Asking follow-up questions is allowed but they must be bound to the initial subject. Manipulating data of the baked AOV textures. Trying to adapt them to look like on final render image is an ill-posed problem, as each AOV is some sort of "layer" of the information the renderer uses to create final rendering. I'd suggest you first check the documentation on the AOVs: Intro to AOVs and Redshift: Baking. If you still have end-user questions, you're very welcome to ask them on our Support Center. To the best of my knowledge using AOVs from the render settings is supposed to work with the Bake tool as long as you use AOV Manager to set them up. The effect of "green normals" that you observe is likely the unexpected coordinate system for your normal data. Namely, Redshift is always working with objects in worldspace, hence the normal data is also represented the same way. The blueish normal maps are typically those that are expressed in tangent space. Unfortunately there's no built-in AOV that does this for you. To achieve this, you could potentially leverage the "Store Color To AOV" node for that, although this would require adjusting your node material setup, e.g. like below: [image: 1738227286463-8f2f671d-15d9-437f-b6f3-e77f72169666-image.png] Cheers, Ilia

Hi James, from my side there's nothing to add to Gheyret's answer. As of now there's no such option to achieve transparency of the GeDialog. Using third-party libraries could be a potential option, but we don't provide any support for this case. Cheers, Ilia

Hello @uogygiuol, Thank you for the added details. Yes, reducing the complexity of questions is the right thing to do, thank you for doing tit. Essays are counterproductive, as we then tend to overlook things (q.e.d., I overlooked the fact that you wanted to mangle the scene file in this thread). In general, trying to mangle a file beforehand is not a good route, as you always risk invalidating the file. For your very specific scenario - very simple scene graph, just geometry, no materials, animations or other dependencies - it could make sense. I briefly talked with the owner of our GLTF-importer, and we do not do any sanity checking, e.g., comparing nodes with meshes. So, you could just 'clean up' the scene graph ("nodes") of the file, and Cinema's GLTF importer will then just ignore extra data in fields such as "meshes". How fruitful this will be, you will have to find out yourself. I already had the hunch that your are here surfing on the edge of what is sensbible, and GLTF JSON files which translate to gigabytes of memory are certainly an edge case, due to the fact that text-based file formats are usually a bad choice for such heavy data. Using Python to Read JSON My guesstimate would be that when you throw a GLTF JSON file at Python's JSON parser - which takes five minutes to load in Cinema 4D - to mangle it, you end up with a net-loss or tie, because you loose most or more than the won time in that Python JSON stage. Python's json module is mostly written in C to make it performant, but that is still a lot of JSON to deserialize, modify, and then serialize. One idea could be to use re, i.e., regular expressions, to find the "nodes" section in that file, just deserialize that from JSON, modify it, serialize back to a JSON string, and write it back in place, and by that sidestep having to deserialize that whole file. The problem with all that is that json.load allows you to pass a file object, allowing you to bypass the Python VM entirely and let the data reside in C until the parsing is done, while re does not allow you to regex a file object directly (AFAIK), you always must read the file object into lines or chunks to then pass these strings to the re module. I.e., you would have to load that whole file into a Python string first. What would come here out on top, I have no clue, but my hunch is that re might loose, as Python's string handling is not the fastest. Alternatives might be 3rd party libs such as isjon (a lazy JSON loader) but I do not know how performant it is. For this section it would make a huge difference if you could predict the position of "nodes" in the file, either exactly as a chunk offset, or in the form of 'I know that it is always very close to the end, so let's regex parse the file in reverse'. Using a Binary File Format But the fact remains that text-format file types, e.g., JSON GLTF, become extemely ineffcient once you pass the ~100 MB barrier. Using something like binary GLTF or another binary format such as FBX will likely speed up your Cinema 4D loading times quite a bit, no extra steps required. And to be clear, text-based file formats are always wildely ineffcient. It is just that below the ~100 MB barrier (adjust for the beefiness of your machine), you can drown that inefficency with pure computing power and have the nice advantage of a human-readble file format. Cheers, Ferdinand

Hello @ECHekman, It is very unlikely that this will ever change unless we do a fundamental rewrite of our UI core (which itself is not that unlikely but there are no current concrete plans or an ETA, Cinema 4D could keep using its current UI core for another decade). What Redshift, or more concretely things like the foreground object, are doing, is not loading or modifying palettes. They are modifying the state of the command via CMD_HIDDEN. For things where you usually do not have control over the command implementation, you can register a CommandGetStateDelegate for a specific command ID. This delegate will be called whenever the state of the command is queried, and you can then modify the state as you see fit. Cheers, Ferdinand Code // Demonstrates how to register a CommandGetStateDelegate for a specific command ID, allowing us to // override the CommandData::GetState behavior of the command, i.e., how its enabled/checked/ // hidden (and more) behavior is. // // Doing this is usually only necessary if the command implementation is not under our control, as // for example, for scene elements (NodeData, ObjectData, etc.) where we usually do not implement the // command ourselves but let Cinema 4D handle it. // // NEVER IMPLEMENT ANY STATE DELEGATES FOR COMMANDS THAT YOU DO NOT OWN. // This is the state handler for the foreground object command. It will hide the command if the active // renderer is Redshift. namespace maxon { MAXON_DECLARATION_REGISTER(CommandGetStateDelegates, NumToString<Oforeground>::value) { CommandGetStateDelegate delegate = [](cinema::BaseDocument* doc) -> Int32 { Int32 state = cinema::CMD_ENABLED; if (doc) { cinema::RenderData* rd = doc->GetActiveRenderData(); if (rd) { const Bool isRedshiftActiveRenderer = rd->GetDataInstance()->GetInt32(RDATA_RENDERENGINE) == VPrsrenderer; if (isRedshiftActiveRenderer) state |= cinema::CMD_HIDDEN; } } return state; }; return delegate; } } // namespace maxon

Hi Ferdinand, Thank you for your answer. No, I'm no developer, and yes, I work for a business looking to automate still image production in the rendering pipeline - trying to reduce human error as much as possible, and speed up our process/volume. It's all about money in the end sadly. I was curious to know if something was possible to place an object automatically on the "shooting table" flat in a way that the place tool allows - we have automated every other step of our process and this is the only one left that is a challenge. This is a much bigger problem than I thought it was. Thank you again for understanding I'm likely not a developer - it's frustrating when developpers always think everyone is like them, and it should evident our questions are ridiculous. Markeee.