Topics created by Cairyn

Thanks. In the meantime I made some more experiments, and it seems the problem is limited to when you click Execute in the Script Manager or the Customize Command window. I created a keyboard shortcut and embedded the script as icon in the GUI. In both cases, the status bar gets correctly updated regardless of what window was active / received the key press, and where the icon resides (same window, other window, undocked toolbar). It seems the Python interpreter is not blocking the message loops in these cases. That makes the question somewhat academic, because shortcut or icon (or menu but I did not check that) would be the common ways to start the script; starting it from the Script Manager is common during development but irrelevant in practice. I'm curious to hear what the developers will say about the message loops though.

@m_adam Thanks for the confirmation! (I swear I'm not doing this on purpose...)

@m_magalhaes thanks, that'll do!

Hi, Correct it was an unknown error. And yes it not only affect Layer but any kind of GeListNode inserted if they are not already in a hierarchy. I marked this topic as solved, and will bump the topic once a fix is included in a public release. Keep in mind this is a Python only issue. Cheers, Maxime.

@m_adam okay, good that it's found... I guess I can go with the code above for now that excludes tags explicitly and gathers them in a different recursion. As per the original issue (there is no function in the API that returns the currently visible tracks in timeline n), I guess I would need to make a requirement/suggestion on Maxon's site? Or is something like this planned already?

Hi Cayring this is indeed a bug I'm going to report them and fix them (both for BaseMaterial and shader) as soon as possible :) If you have other cases like that please report them. I set the topic as solved, I will bump this topic once the fix will be available. Cheers, Maxime.

@m_adam Thank you for the confirmation and the reading suggestions. Just for context, this is a general conceptual question and not connected to a specific code issue. I noticed the behavior while doing some test scripts with id() and is. It is worth noting that these Python properties need to be used carefully in concert with C4D objects. (I wouldn't exactly recommend using pointer comparisons in C++ either ;-) ) I will include an "advanced" chapter in my Python/C4D book to mention this.

Thanks for the confirmation. I shall treat the extra link directions as nonexistent then ;-)

Thanks, it's good to know that there are internal functionalities actually using these flags!

@m_adam Thanks for the info! I knew I was still missing a few flags ;-)

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.

@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.

@m_adam Thanks, yes, you're right, a timer may be my best choice here to avoid too much load on the system. Checking the project list every 3 seconds or so should suffice for the usecases. And since I'm in a GeDialog, the timer function is easy to implement. (I just have to take care that within the 3 seconds, the state of the dialog may be inconsistent with the actual system state.)

Thanks for the confirmation. I guess I'll use an empty group then and fill in the scrolling group in the code.

That's ok, I have meanwhile refactored everything* into a MessageData plugin anyway so the plugin will work** even if the dialog is closed. *Everything except for timer stuff, which for some reason works differently for a dialog than for a message plugin. **There are some strange effects like hanging or crashing application on Close, when the dialog is in certain states. I will need to investigate whether this is an effect of the missing CoreMessage calls or something that happens now due to refactoring.

@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 again; just to close off the topic here's what I ultimately found: A lot of the delay that causes the choppyness of the motion is apparently an issue with EventAdd(). I require this call to update the Attribute Manager for the current camera, and to start the recalculation of the interactive render region. But as it seems to refresh about everything, the call causes a noticeable delay before the next viewport refresh comes through. (It is surprising that this call takes longer than a redraw of the viewport, and it is very hard to time as EventAdd() just posts a message to the queue, so I cannot actually measure the execution duration.) The scene camera is slower than the viewport camera. CollieMouse treats both the same, in fact, all handling is done through a CameraObject that I get in a similar way as the one you posted above. Yet, the redraw is slightly slower by itself, and there are apparently things indirectly happening for a scene camera that take even more time (even when expressions are switched off). There is not much I can do about that except allow the user to suppress certain refreshs for the sake of a smoother Space Navigator experience. I'm still not sure what some of the DrawViews() flags exactly mean, by the way. I guess I can ignore the HIGHLIGHT ones for now, but what are INDRAG, INMOVE and FORCEFULLREDRAW really doing, and when do I need to use them? I see that you use INMOVE in your code (but not NO_EXPRESSIONS which surprises me).