Topics created by Cairyn

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