Thank you for @Dunhou answer. It was ultimately completed in JSON format

Hi @Neekoe,

That's great to hear you've managed to solve the issue!

For your future postings please note that according to our Support Procedures:

We cannot debug your code for you and instead provide answers to specific problems.

This effectively means that you're welcome to ask your questions and attach the code snippet that demonstrates your question or issue you're struggling with. However, we cannot debug your entire codebase, so you have to isolate your specific question and the corresponding part of code yourself before asking the question.

Cheers,
Ilia

Thanks @Neekoe to have shared your solution and thanks @Dunhou for helping.
When you pass LV_TREE the Draw method is not called to have it called you need to pass either LV_USERTREE or LV_USER.

Cheers,
Maxime.

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

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:

8f2f671d-15d9-437f-b6f3-e77f72169666-image.png

Cheers,
Ilia

I get it, thanks for your reply and keeping the idea.
If there are any workarounds or alternative solutions in the meantime, please let me know.
I look forward to any updates regarding this feature in the future.
Cheers~

Hi thanks for the question, I've opened a bug report, for the moment the only workaround would be to remove the Morph and re-add it.

For the moment the name in the treeview is only updated when manually edited from the treeview and on the insertion of the item in the tree view.

Cheers,
Maxime.

Hi @i_mazlov
I can't use C++ at the moment, so I thought I'd try MultilineEditText for my purposes.
I looked for This post in the forum and now I have some ideas.
Thank you for your reply!

Cheers~

Hi @heytraile,

Please have a look at our Support Procedures: How to Ask Question section. Usually it is very helpful if one provides a relevant code snippet, demonstrating the issue. This helps to reduce the room for any misinterpretations of your original question.

Regarding the issue you're describing, the "null" being logged to the console is often a symptom of an implementation issue within a function that overrides the base implementation. Specifically, if a function (such as Message() or RestoreLayout()) is expected to return a particular type (e.g., bool), but instead returns None or a mismatched type, it can result in unexpected behavior and the "null" log.

Cheers,
Ilia

Yes, we will treat it as a bug. Apparently we implemented it, but then someone disabled the implementation (probably because it caused performance issues or something like that), and then we forgot do follow up on that disabled implementation. Generally we cannot give ETA's for fixes but we try to do them in a timely fashion, i.e., within a couple of minor releases such as 2024.1, 2024.2, 2024.3, etc. I am not the dev here, so I can give even less guarantees. We will update this thread when something blocks us from fixing this in the near future.

And yes, it does work in C++. The reason why this is not working in Python is because of the C++ API changes with 2024.0. This link shows how you sample things in C++, the changes revolved around making sampling a field a const operation, i.e., an operation which does not change data on the object. Which was before not the case and now requires that mutable data to be manually passed arround as the extraData as shown in the example. The changes were carried out to speed up the core of Cinema 4D.

Cheers,
Ferdinand

Hello @qq475519905,

Thank you for reaching out to us. Your question is very ambiguous. But given your posting history, I assume this is a development question and not an end user question. I.e., you are a developer who struggles with setting up a plugin which is being loaded, and you are not a user struggling with installing someone else's plugin (the latter would be out of scope of support for the developer forum).

We have plenty of Python plugin examples on Github, for anything more concrete, we will need a more concrete question from you. Most importantly executable example code which highlights your problem. Please have a look at Support Procedures: How to Ask Questions.

Cheers,
Ferdinand

Hey @lednevandrey,

without wanting to be rude, I really struggle with understanding what you want to convey. Material[c4d.TEXTURETAG_PROJECTION] = c4d.TEXTURETAG_PROJECTION_UVW does not work because Python is case sensitive and you gave your BaseMaterial instance the symbol material. So, Python is complaining about that.

But as said before, a material, i.e., BaseMaterial is not the right place to set the projection. It is the counter part to the thing you see in the Material Manager of Cinema 4D and has no projection. The projection is set in the Material Tag, which slightly confusingly is called TextureTag in the API.

Cheers,
Ferdinand

"""Assigns the first material in the document to the selected object and sets its projection to UVW. """ import c4d import mxutils doc: c4d.documents.BaseDocument # The currently active document. op: c4d.BaseObject | None # The primary selected object in `doc`. Can be `None`. def main() -> None: """Called by Cinema 4D when the script is being executed. """ if not op: raise ValueError("Please select an object.") # Get the first material in the document. material: c4d.BaseMaterial = doc.GetFirstMaterial() if not material: raise ValueError("No materials found in the document.") # Get the first existing texture tag on #op or create a new one when none exists. tag: c4d.BaseTag = op.GetTag(c4d.Ttexture) or op.MakeTag(c4d.Ttexture) if not tag: raise ValueError("Failed to get or create a texture tag.") # Set the material and projection. tag[c4d.TEXTURETAG_MATERIAL] = material tag[c4d.TEXTURETAG_PROJECTION] = c4d.TEXTURETAG_PROJECTION_UVW # Update the Cinema 4D UI. c4d.EventAdd() if __name__ == '__main__': main()

Great to hear that you found your solution! Do not hesitate to ask more questions when you run into problems while exploring our Python API. But just as a heads up, we prefer users opening new topics for new questions. For details see the Support Procedures linked above.

Cheers,
Ferdinand

Hi sadly it is not possible for the moment, I will talk to the responsible team to see if that's possible.

Cheers,
Maxime.

Hey BigRoy, sadly it's still impossible, I will start the discussion again, thanks for the reminder.

Cheers,
Maxime.

I was just looking for the exact same thing and would second the need for these 3 hooks without the need for a Python Generator object.
It would make the pipeline integration of C4D much more straightforward. @m_adam

Hi @BigRoy,

in python the lifetime of the objects is handled automatically so you're right, there's no need to do anything special to destruct the object.

Good job on your project! Thanks for sharing it with the community!

Cheers,
Ilia

Hi @datamilch,

you can use the EVMSG_CHANGE message as a trigger to check your objects for changes. The timer approach might seem imprecise from the first glance, but can actually be used, I don't think there're any significant reasons against it. Additionally, the recent change was made to make BaseList2D being hashable. This effectively means you can operate with your objects in a dict.

The python tag approach is the least efficient, although would still work, yes.

You're saying your GeDialog plugin uses "mostly the ideantical userdata". If it was "identical", you could potentially use c4d.gui.DescriptionCustomGui with the SetObject function to make it point to your object. This way you can avoid hassling around all the data sync, because it is all handled as a built-in functionality of this class. This is how the attribute manager effectively works, or the Active Object Dialog as well.

For your further postings please follow our guidelines on How to Ask Questions, namely:

Please consolidate your questions into a singular posting by editing your last posting

Cheers,
Ilia