Hi @BigRoy,

For the alembic camera, you can use c4d.MSG_GETREALCAMERADATA, for example:

def main(): data = dict() op.Message(c4d.MSG_GETREALCAMERADATA, data) print(data['res'])

Another option (which would work for other object types as well) would be to check type of the object's cache using GetCache().

Cheers,
Ilia

Ok, found out what is wrong.
The code inside the Output is being executed in multiple threads.
So, one thread may be calculating the color of one object but the data I have in my struct is from another object being calculated by another thread.
Is there any way to force a shader to be only calculate in a single thread?
Or, is there any way to get a unique value from each object so that I can store a set of structures in the InitRender method, and detect which one is being rendered in the Output method and use the correct structure of data?

Hey @spedler,

Thank you for reaching out to us and for pointing out that issue. We are aware that our code signing documentation requires an overhaul. This not only means updating the rather dated MacOS guide, but also providing a guide for Windows since code signing also has become more and more important under Windows. And although not yet as restrictive as MacOS, the Microsoft Secure Future Initative is pointing to a future of execution policies on Windows similar in strictness to the one's found on MacOS.

Cinema 4D itself is evolving in a similar fashion, as recently lined out in About the necessity of code signing plugins. We have currently no immediate plans to make code signing for all plugins technically mandatory, Cinema 4D is currently still loading unsigned binaries, but we strongly encourage users to (properly) sign their plugins, especially under MacOS. What has changed since Cinema 4D 2024, is that Cinema 4D will not load binaries with an expired certificate anymore (note that an expired certificate is not the same as an expired license, see the linked posting for details).

I currently plan to update the guides in 2025 Q1 or Q2. It was actually already planned for 2024 but I never got to it. But just before I left for vacation I at least already requested the necessary licenses to further research and write the new guides 😉 But this is neither my current or next task. However, given the relative closeness of the task of overhauling the code signing documentation, I will probably not 'monkey patch' the current documentation.

When there are any questions regarding code signing plugins for Cinema 4D on either Windows or MacOS, please do not hesitate to ask or discuss them here.

Cheers,
Ferdinand

PS: I am still on vacation, so I will likely not respond to any follow-ups until I am back.

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

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

Cheers,
Maxime.

Alright! Thats a sweet improvement.

Okay no worries we'd already moved to the method you described!

Does this change back propagate to earlier versions like 2023?

Thank you very much, Ilia.
I will look into both approaches.
I only have to check it at the begining of the calculations of the shader, so the best way should be to make in the InitRender method, right? That way, all the possibly "slow" stuff only gets calculated once.

Hi @César-Vonc ,

Cinema 4D uses OS clipboard to some extent, namely as you can see from the CLIPBOARDTYPE enum there's text and image clipboard options. For other Copy&Paste functions the built-in clipboard system is used, hence the OS clipboard stays untouched.

Cheers,
Ilia

Hi @John_Do,

Please note that this forum is for the public APIs of Maxon products related topics. We unfortunately cannot help with the end user issues. Please ask your end user questions in our Support Center. This and also other important considerations are mentioned in the Scope of Support part of our Support Procedures.

With that's said, your question gives a fuzzy impression on what exactly you're asking about. Namely, you're talking (presumably) about the CopyToClipboard() function, but then also claim the issue is not there, rather when you paste this bitmap in the PV. Could you please share some code snippet, which highlights the issue, especially the pasting part, which seem to not work as expected.

Please also make sure you've setup the Picture Viewer's View Transform to meet your needs.

In our internal bug tracking system I'm also seeing 2 issues that we already keep track of:

A-B comparison issue that was just recently fixed and is not yet released Picture Viewer issue with OCIO enabled when using EXR files

However, none of these seem to be specifically related to your case.

If you're still having this issue and it is not related to our SDK, I would kindly ask you to reach out to our Support Center.

Cheers,
Ilia

Thank you very much, Ferdinand. I understand.

@i_mazlov Thanks much for explanation.

@i_mazlov Thanks a lot for your time.
You answered my question brilliantly.

@Manuel Thanks ! Still here in 2024.5.1

Hi @ferdinand ！
Sorry for late reply, and thank you very much for your detailed and thorough explanation, and for taking the time to explain the relationship between linear algebra and trigonometry in the context of computer graphics and transformations.
As a beginner, all I want to do here is to practice as much as I can with the knowledge I've learned, and I apologize if I didn't explain clearly.
Yes, in the code I want to implement is placing two tangent handle relative to the two input objects a and c.
Compared to calculating with trigonometric functions, your suggestion seems more straightforward and clear, and I never would have thought to use vectors to achieve this, I need to keep practicing.
I will take the time to review the thread you mentioned.
Thank you again for your support and guidance. Thank you very much for your insights!

Hey @rui_mac,

thank you for reaching out to us. In general only shaders which are volume shaders have access to the object for which they are being called for. In Python (or in COFFEE) you cannot implement volume shaders and therefore cannot access the object which is being rendered.

When you are implementing a volume shader in C++, you can do this (untested pseudo code):

cinema::Vector MyShader::Output(cinema::BaseShader* shader, cinema::ChannelData* cd){ // Get the volume data from the channel data. cinema::VolumeData* const vd = cd ? cd->vd : nullptr; if (!vd) return COLOR_RENDER_ERROR; // Get the ray objects. for (cinema::Int32 i; i < vd->GetObjCount(); i++) { const cinema::RayObject* const ro = vd->GetObj(i); if (!obj) continue; // Attempt to find the object this ray object has been constructed for. const cinema::BaseObject* const op = ro._texture_link ? ro._texture_link : ro._link; if (!op) return COLOR_RENDER_ERROR; // Do stuff with the object ... } return COLOR_RENDER_ERROR; }

Cheers,
Ferdinand

Hey @rui_mac,

no, they do not match the uvw coordinates. They are weights, please have look at the example I have linked to above, it likely does everything you need. GetPolyPointST expects a value in local object coordinates and returns weights for the polygon UVW coordinates. You get then your final coordinate by the bilinear interpolation of the UVW quad over the s,t weights. You can of course technically replicate all the math yourself, but as Ilia has pointed out this would be out of scope of support.

Cheers,
Ferdinand

Sure, no worries, it's not a high priority, more like a nice to have feature. We can manage without this. I was just wondering if something like this could be possible already in the context of node materials. Thanks.

OK, clear, thx!