Ok, I will. Just need to remove all not-needed things

Ok, I will give it a try and let you know. Thanks.

As stated before, we are working on it and it will be released in the future. I can't say more. Regarding your question @Aaron this will be possible.

Thanks Sebastian! Looking forward for a fix. ;) Meanwhile I'll take care of your recommendation. Best, Robert

Hi Riccardo, I think the issue is solved because there is no any issue. Some not good methods of software distribution just confused us. Btw, what benefits different parameters of SetPluginPriority() give to us? For example the xdll has several plugins like materials, shader, tags and renderer. Even some icons with plugin ids. What priority is better to use in this case? I see https://developers.maxon.net/docs/Cinema4DCPPSDK/html/page_manual_module_functions.html For example, what is C4DPL_INIT_PRIORITY_ADVANCEDRENDER: Does it give higher thread priority during some PV rendering task? Or does it just load the plugin before other renderers and give the chance to lock system resources before others?

@m_adam Oops. Okay, GeRayCollider works only for polygon objects, as does GetPixelInfoPolygon. The idea was to provide a new selection method for arbitrary objects by just checking all hits of a scattered PickObject within a radius, and then select the nearest hit. For that, I need to be able to hit splines and parametric objects as well. Okay, I guess I can still do that in C++ then, thanks.

HI Andreas, no worries, this question was not exclusively targeted at Maxon, the opposite is the case. I was hoping for some information by other users here, like @kbar or even @m_adam (back in the days Maxime was not associated with Maxon. ;)) Meanwhile, I'm going to build a toolchain and see what works for me. I'll report back here if I have something to show. That may help someone else.

Hi Sebastian! Turns out my issues are two seperate, but equally self inflicted problems :) Inserting and activating works as expected, I am blocking the update with some custom UI stuff so I will have to find a solution for that. Calling EventAdd() in the closeEvent of the UI doesn't do anything. Is there another way to force Cinema to update everything? Killing the document not only doesn't update, but actually crashes Cinema, because I am trying to kill the document from within a callback that is reacting to MSG_DOCUMENTINFO_TYPE_LOAD. I am doing some more involved environment management and sometimes I have to close a document after loading. I have a workaround that will have to do for now. In the callback I change the document path to a string I can then look for in EVMSG_CHANGE. When I detect my string there, I can then kill the document. It's not very elegant and if anyone has a better solution I would be very happy, but otherwise consider this problem solved :)

Hi mafster, thanks for reaching out us. With regard to accessing images being available in the Picture Viewer, I'm sorry to confirm that there is no PictureViewer-related classes/functions exposed in the API. This is valid for both C++ and Python API. Best, Riccardo

Hi, good we got you going It is not wrong per se to use multiple plugin directories. Actually Cinema 4D R20 was specifically designed to have multiple ones. You just need to make sure not to have duplicate plugins in these directories. Cheers, Andreas

Hi line6dude, thanks for following up. With regard to registering Tokens in c++, given that it's not a complex task, requires at least a minimum background of C++, familiarity with Xcode (or VisualStudio) and understanding of our Cinema 4D tool-chain. If you feel comfortable in becoming familiar with such concepts, please open a new thread to tackle the argument. Best, Riccardo

@m_adam Although I didn't get a solution to this problem, I found a solution to my own problem. Thank you very much.

Hello @r_gigante Thank you for your time and answer. I will try the other way then. Best, Ogers

Thank you Maxime. My current solution looks pretty similar to yours and works . Implementing an own gadget is of course out of scope - I don't even get paid for that.

Thanks for confirming my suspicion :)

Ok, thanks!

Hi @rownn, thanks for having provided further details. Assuming that you're aware of the limitation in terms of appearance that you might face by using the functionalities delivered by GeClipMap, the only way to go to access a bitmap which is supposed to contain a rendering of the scene in Python is to execute the rendering invoking the BaseDocument::RenderDocument() and pass the BaseBitmap you intend to manipulate via the GeClipMap. Best, Riccardo

Just tried now… It seems to work perfectly! Thank you! I don't want to boring you, but, please, don't disable this super feature in python. Instead you could update the documentation specifying well how to use it.

Hi, we are glad @rui_mac you were able to solve your problem. I'd just like to quickly recap to make this also clear for future readers. Visual Studio has two "concepts" two organize your development work. Projects, which is basically a set of files plus a bunch of configuration options and instructions for the tool chain (compiler, linker,...) to build a binary (in our case here always a plugin library). Solutions, which are collections of above projects plus some additional global configuration data and more important, information on dependencies of the contained projects. Now, our project tool can and does create both projects (for your plugins and for our frameworks) and a solution containing all of the above (actual workflow described in our docs under the links provided by Riccardo earlier on in this thread). So when you open such a solution and build your plugin project, also the frameworks it's depending on should be built.So, this is the way to go (project tool -> solution and projects -> open solution in Visual Studio). But if you instead open just one of the generated projects directly, Visual Studio will implicitly generate a solution for you, but it still lacks the framework projects and the build of the opened project will fail (error: unresolved symbols, i.e. function or class names normally provided by our frameworks and used in the plugins code can not be resolved). I hope this makes it a bit easier to understand. Cheers, Andreas

Ah, thank you. I didn't take a look at vec.h. Meanwhile, I already wrote a conversion unit to handle all sorts of formatting. Thought, it was possible to modify the intern string conversions somehow. But nevermind, all works pretty well. :) Cheers, Robert