@JasenLux said in Automate Turbosquid uploading with Python script: Even if in the morning I've got a bunch or renders done over night - and it's all automated - I'd be very happy. A more or less automated rendering could be achieved by using the native Render Queue if you create your files with some rigid discipline. Start out by creating a base C4D file that contains the necessary cameras and render settings with some appropriate naming. The render settings should be hierarchically ordered, with the basic setting on top and all the different resolutions as children of that setting, with only the necessary settings overwritten. If there are TurboSquid requirements that you cannot achieve with render settings, you can create some takes that offer the necessary changes (this might be the most difficult part, as you may need to overwrite parameters in tags that you don't have in the basic file, but only create with your project, but that very much depends on what you really need to change, I am not familiar with the TurboSquid requirements. Once that file is set up, you only need to copy your master data into that, save it under the appropriate name, and in the evening add it a few times to the render queue. As you can select the take, rendersetting, and camera for each job, the prepared file can be rendered out without saving multiple versions of it first. (That sounds like some script would make it easier, too, but I just fleetingly looked at the Python and C++ documents about BatchRender, and it doesn't look as if you can control the job settings individually?) I recognize that this would only be good for the rendering part, but... if TurboSquid doesn't offer an official, supported web interface for uploading, then as @zipit said, "hacking" into the protocols would be just one gigantic mess that you don't really want to spend money on as it is very likely to break at the first opportunity. Thanks for mentioning me

@m_adam Thanks! Thats a perfect explanation that solves many of my issues - even in some of my other Plugins. I am sorry, I did in fact refer to c4d freezing when I said crashing. Sorry for the confusion.

@m_adam , AddEventNotification was exactly what I needed. I created a notification to NOTIFY_EVENT_UNDO, and then add my object to it. Now if I delete anything from my object after a polygon is deleted, it will be restored with Undo. Thanks! case MSG_NOTIFY_EVENT: { CHECK_BREAK( data != nullptr ); const auto eventData = static_cast<NotifyEventData*>( data ); if( eventData->eventid == NOTIFY_EVENT_UNDO ) { NotifyEventMsg* notifyMessage = static_cast<NotifyEventMsg*>( eventData->event_data ); CHECK_BREAK( notifyMessage != nullptr ); if( notifyMessage->msg_id == Int32( UNDOTYPE_DELETE ) ) { eventData->doc->AddUndo( UNDOTYPE_CHANGE, Get() ); } } break; }

But no plug-ins in R21.207 (demo version) possible? The LAZPoint plugin from cinemaplugins.com would be a nice thing for me if it works for me. But it has to be installed on Cinema4D-R21, with r22 or r23 it doesn't work. To test it, I want to run the LAZPoint demo plugin on a demo version of Cinema - r21. R21-Demo is already running and the LAZPoint-Demo-Plugin is already in the directory \ C4DPlugins and I have registered this directory in the program defaults of R21. But it doesn't work. Other plugins that are trying to be loaded also do not run, none of them run. Tried on 2 computers (Win10 64 pro and win 64 home). What's wrong? ----- Orginal in german: Doch keine Plug-Ins in R21.207(Demo-Version) möglich ? Das LAZPoint-Plugin von cinemaplugins.com wäre eine feine Sache für mich, wenn es bei mir läuft. Es muss aber auf Cinema4D-R21 installiert werden, mit r22 oder r 23 geht es nicht. Um es zu testen, will ich das LAZPoint-Demo-Plugin auf einer Demo-Version von Cinema - r21 laufen lassen. R21-Demo läuft bereits und das LAZPoint-Demo-Plugin liegt bereits im Verzeichnis C:\C4DPlugins und ich habe dieses Verzeichnis in den Programvoreinstellungen von R21 angemeldet. Es läuft aber nicht. Auch versuchsweise ebenfalls zu ladende andere Plugins laufen nicht, keines läuft. Auf 2 Computern versucht ( Win10 64 pro und win 64 home) . Was läuft falsch? [image: 1604162815376-aad98a1d-79bf-442b-9949-8c736404ca0e-image-resized.png]

"I warmly recommend cloning the whole document on a temp doc" Thanks, I'll try working on a clone. I had the impression that the document passed to the videopost was already a clone of the original document, but perhaps this is not the case for viewport rendering? "With regard to your issue, I'm a bit confused by the need you have to call BaseDocument::AnimateObject() or BaseDocument::ExecutePasses() when the VIDEOPOSTCALL in VideoPostData::Execute() is VIDEOPOSTCALL::INNER. Actually when you're in this step, you can already access and query the VolumeData to retrieve all the relevant information about the scene elements (like RayObject, RayLight and so on)." -We have some good reasons for working with the basedocument directly, rather than the data provided from the VolumeData. "Consider that this approach is sub-optimal since you're going to double the resources used to store the current document." -OK. This should be fine for our purposes. Our plugin actually provides custom rendering commands, that are the preferred way of rendering with the plugin. The videopost functionality is added as more of a convenience in our case, to make the plugin work nicely with things like viewport rendering, material preview etc. /Filip

This bug is now resolved in R21 sp2. Cheers, Maxime

Hi Frank, thanks for reaching out us. With regard to your request, aside from confirming that nothing comes with Python API for obvious performance reasons, in C++ the nearest thing you can find is KDtree - as already pointed out by @zipit - or other similar accelerating structures. On top of these notes, I would consider this topic more a general programming / algorithm-related topic which could find, based on the contour conditions, different "better" solutions. Best, R

@Cairyn and @r_gigante Apologies for the late response. Yes, the ExecutePasses works as expected. Thanks for the solution. I can't use the SetMg()/GetMg() because the script is part of a larger base code which is not limited only to the PSR tag. Thanks again. Have a great day ahead!

Yes, C4DAtom.CheckType() in Python. Thanks for the confirmation, it bugged me that it was only in the Python doc but not in the C++ doc.

Hi @Cairyn thanks for spotting it out, it's an issue in the python documentation, if you take a look at the C++ documentation it's said that it supports only Objects and Tags (see BaseDocument Selections Manual). (I will fix the Python doc) On other hand, I confirm to deselect all objects/tags the best way is to call SetSelection with None/nullptr. And finally, as zipit said, in the end, it's only a wrapper around BIT_ACTIVE with the benefic of GetSelection, that the selection is cached so you avoid the iteration on the whole scene. Cheers, Maxime.

@r_gigante Hi Riccardo, Thanks for the explanation. I wasn't sure that a "Solved" thread would still get revisited by SDK team members. As Manuel mentioned "I'll come back when I got more information", but the thread was set to solved, I wasn't sure the thread would get an update. Also, others visiting the forum (now or in future) might be misleaded by the state of the thread, thinking that the bug has been fixed, while it actually isn't. But now I understand a "bug fixed" tag is being added. Seems I need to pay more attention to the tags, as I assumed these tags were added by the creator of the thread. As such, I never really paid any attention later on, as I assumed the tags I added were the only ones to be available for that thread, and only the unsolved/solved state would change as a result of a resolution. Thanks for clarifying.

Thanks @s_bach This is very helpful. Best wishes.

Did it as you said. They've just answered. It's a know bug they said. Thanks.

Hi @gheyret, thanks for reaching out us. Although @zipit has already provide an exhaustive answer to the topic (thanks man!) , I warmly suggest to look also to this blog post[URL-REMOVED] from @fwilleke80 and also to have a look at Navigation in Lists and Trees section on the GeListNode Manual. Best, Riccardo [URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

@zipit said in How to handle C4D Unicode in Python scripting?: well, that API object names thing is a flaw of Python 2. So working as expected or not as expected is a bit a question of the point of view. If you got the string passed from any other source the problem would be the same. Right. The main thing is to understand the issue, and then to write the chapter in a way that explains what to watch out for. (I do wonder how third-party modules would do with a name string passed to them from a script that reads them from the API... well, another bridge to cross another day.) Python 3 clearly is superior in that respect, as there is no unicode class and all str objects are unicode (what they appear to be already in C4D, but with matching len, index, and slice capabilities). On a more productive note: I think that focusing in Unicode strings isn't really that important for Python stuff in c4d, since object names should be something you largely ignore as they are a unreliable source of identification and only are rarely important in other contexts. Hmm, I am not sure whether I would agree to that. Good naming is essential to find your way through complex scenes, and a good naming schema can be built in a way that is friendly to string search and comparison criteria, esp. if you can build your own scripts to perform the search and selection. I just point at the _L _R naming schema for joints that is common in C4D's docs. Of course, if your objects are all named Cube, Cube.1, Cube.2, Cube.3, then name-based identification may be unhelpful Anyway, I am not the person to judge that, as I am only teaching Python to interested users. What they do with it is their own decision; I just have to point out the crucial points so they can apply the code to their own concepts.

@s_bach said in Howto add a Field input to a python plugin: FIELDLIST works fine - i think i got an strange error before and trying CUSTOMFIELDLIST etc. solved

Hi, well, aside from the "at least I am done with it"-approach of just adding 24 hours to each license, there is the static method UniversalDateTime::FromValues() which should be close enough to a FromString(). There is also UniversalDateTime::GetNow(). But the description on that is a bit ambiguous. It says "Return[s] the current date-time object of the current time zone.", while the UniversalDateTime class description says "Class that represents the Universal date-time (UTC+0000)". Unless I am overlooking something here, I would say both cannot be true at the same time, and would expect UniversalDateTime::GetNow() to actually return the current time in UTC +0 (as a UniversalDateTime). The problem with DST is, that it is not anything truly predictable. While your problem could be rooted in a bug, there is a rich history of big organisations struggling with DST (Microsoft, Apple, etc.) and using DST makes you dependent on them maintaining their OS/services properly. On a more light-hearted note: When dealing with standardisation of human conventions I always have to think of this XKCD [image: unicode.png] Cheers zipit

hello, I forgot to ask, where are you running those commands ? on a script, a dialogbox, a nodedata ? Thanks for your time trying to isolate the problem. Don't hesitate to send us an heavy scene, we can see why the command isn't working. Cheers, Manuel

hello, without more information from your part, i'll close this thread Cheers, Manuel