Congrats, you managed to find one of the most challenging things possible in C4D.

I have written the alternative SpaceNavigator controller CollieMouse for C4D (Windows...) so I was faced with similar issues.

First, C4D does not give you access to the message queue of the OS (or any proper windows functionality). C4D provides an abstraction layer for all GUI functionality so it will work on both Windows and MacOS, but it does not lay open sufficient functions for window control, much less internal OS stuff. I had to link to the Windows API itself, then open my own invisible window to process messages from the SpaceNavigator driver, all in its own thread to prevent deadlocks and busy waits. This ended up very OS dependent.

The issue in communicating with external devices is that you need a listener within C4D, no matter what kind of events you pipe. A listener means you need to access some message queue which waits for events in a non-blocking way. Usually, under Windows you use the standard windows messaging system. I suppose there are other ways, esp. on MacOS. As I have no experience in this OS, I need to leave it to you to look for a proper cross-application queueing approach. C4D does not have any such system and hides the actual OS GUI windows and their messaging system from you.

Second, there are no direct Pan/Zoom/Rotate functions. The position of the camera is controlled by its matrix. Moving the camera means you change the matrix appropriately. (For a scene camera, you will need to take into account that it may be part of a hierarchy with inherited position/rotation through the parent objects.)

But beware! There are different views which need to be handled all on their own - Perspective, Parallel, Axonometric... The behavior of the camera depends on the selected view. Furthermore, there are scene cameras and viewport cameras (internally the same data structure but you need to know what camera you are working with); then there is the pivot that is needed for rotations (which by the way is still not supported by the built-in space mouse controller). I suppose you will not want to support all these details.

Third, I'm not sure what you mean here... a GUI simulator that sends OS messages to the application, like in webapp testing? Imitating mouse input? This is certainly possible, although I'm not sure about the effectivity. C4D can check the viewport size and position, but as for how to send this to another application, you will again need to look for OS level messaging.

Anyway, this first thing to look for is definitely a way to send and receive messages across applications, whether it be the windows system or some other library. (If anybody reading this has experience in novel ideas, I'll be happy to hear them.)

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

Hello; I am wondering whether the Python version of c4d.utils.ViewportSelect.PickObject() may be missing a return value.

Within C++, I can extract the depth of the picked point with GetZ() on the returned C4DObjectList. (I didn't try this but it has been discussed before on this forum.)
In Python, all I get is a Python list with no such method, and the list contains only objects, not object/zdepth pairs. The help text for the flags indicates that VIEWPORT_PICK_FLAGS_OGL_ONLY_TOPMOST_WITH_OBJ at least should give me a z value ("Picks only topmost object but returns the topmost object with its Z position.") but that may be just copied from the C++ help.

So, while I can identify the object under a mouse click, I cannot find the depth of the hit point.
Trying to get around by using other ViewportSelect methods shows that these apparently only work for polygon objects.

What is the preferred method to find an object under the mouse cursor including the z-depth of the found hit?

Thanks.

Working fine for me, once I correct all the indentations. I am not sure whether your script's indents are okay, since the code is broken up into several code-quotes, but in case it's not: the methods of the class need to be indented under the class definition.

I don't see anything that would work under R19 (my current test) but not under R17 (your version) so this is a bit of guesswork. What is the console saying when you try to execute the code?

You will need to add a line to close the dialog, too, and to transform the returned value into the proper string instead of the index number as string... maybe use a dictionary for value/string pairs.

import c4d
from c4d import gui

dropdown_values = {
                   0:"Child 0",
                   1:"Child 1",
                   2:"Child 2"
                  }

class TestDialog(gui.GeDialog):

    pass_value = 0

    def CreateLayout(self):

        self.AddComboBox(5000, c4d.BFH_LEFT, 100, 10, False)
        self.AddChild(5000, 0, dropdown_values.get(0))
        self.AddChild(5000, 1, dropdown_values.get(1))
        self.AddChild(5000, 2, dropdown_values.get(2))
        return True

    def Command(self, id, msg):
        # print currently selected "child""
        if id == 5000:
            value = self.GetInt32(5000)
            print("got index: " + str(value) + ", value: " + dropdown_values.get(value))
            self.pass_value = value
            self.Close()
        return c4d.gui.GeDialog.Command(self, id, msg) 

    # custom function
    def GetSelectedChild(self):
        return self.pass_value

def main():
    dialog = TestDialog()

    dialog.Open(c4d.DLG_TYPE_MODAL_RESIZEABLE, 132456, -1 ,-1 ,400 ,400)

    value = dialog.GetSelectedChild()
    print "Value after call: ", value
    op.SetName(dropdown_values.get(value))
    c4d.EventAdd()

if __name__=='__main__':
    main()

@bentraje Yeah, the second part was meant just in case you have need for a manual process. GetModelingAxis() takes multiselections of elements into account.
However, I believe GetModelingAxis() works by selected mode (as you can have different selections for points, polys, and edges in parallel depending on whether the point, poly, edge, or object mode is active. So if you explicitly need the point selection and use the method in a script, you may want to switch to the point mode before using GetModelingAxis(). (Also, the actual modeling axis can be changed by the tools, so caution is in order. Personally, this is the behavior I needed, so I didn't make any big experiments.)

You are probably in need of GetModelingAxis() which reacts to object selections or polygon/edge/point selections.

Here's how I determine the pivot for CollieMouse, which is supposed to be the same pivot that the built-in transformation functionality is using:

	BaseObject* objcenter = doc->GetRealActiveObject(nullptr, nullptr); // GetActiveObject() fails with multiple selections?
	if (objcenter != nullptr)
	{
		Matrix centermat = objcenter->GetModelingAxis(doc);
		pivot = centermat.off;
	}

Note: This is R19 C++, but I can see GetModelingAxis in R20 Python as well.

If this is not what you're looking for, you can take a point as vector, transform this vector by the object's world matrix, and get the world "matrix" for the point. If you need more than one point, use the average of those points.

@bentraje The Python tag must be evaluated in every redraw of the scene (not just on every frame but far more often; try this by insert a Print in the code...) because it may not just depend on variables but on values from the scene (e.g. "if the object X is placed farther away than 1000 units then move object Y to..."). Keeping track of original values and comparing them with current values like this is nigh impossible (requiring analysis of code semantics), so the tag will be simply re-evaluated whenever encountered.

You can insert an "early exit" in the tag, of course, by testing for changed variables yourself (as you as programmer have more information on the semantics than the Python interpreter/compiler). But you will need to store the values to compare with somewhere, and you will need to take into account that the execution may not happen in frame sequence (e.g. when the user scrubs the timeline backwards).

As for the original question, I tend to put calculations into Python nodes inside the XPresso because plain math calc creates TONS of XPresso nodes that tend to become very confusing. On the other side I keep XPresso nodes whenever I want to see the affected objects in the circuit directly, or when I need a GUI for adapting something (e.g. Range Mapper with spline interface), or when the node does complicated things that I don't want to reprogram in Python (Hair intersection? ... nah, never used that ;-) ). When the whole thing is easier to maintain as a Python tag in the end, I put it into the tag...

So it's not so much a question of whether the execution is faster, it's pure convenience of the result for me.

You can't divide by a matrix, you need to multiply by the inverted matrix (unary prefix operator ~).
Note that the multiplication in matrix calculations is not commutative.

Now we are at a point where angels fear to tread...

I can't say what exactly the Start/EndUndo system is doing when not properly used in one level, but it definitely doesn't work in a way that supports nesting. Here I just tried a small modification of my previous scripts:

import c4d

def main():
    doc.StartUndo();
    obj = doc.GetFirstObject();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");

    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();

    doc.StartUndo();
    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();

    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");

    obj = obj.GetNext();
    doc.AddUndo(c4d.UNDOTYPE_CHANGE_SMALL, obj);
    obj.SetName("Renamed!");
    doc.EndUndo();
    c4d.EventAdd();

if __name__=='__main__':
    main()

I used the same sequence of five renames, but I nested rename 2+3 into a new Start/EndUndo without closing the outer first.
If you apply Ctrl-Z on that, you will find that the first Ctrl-Z reverses the last three renames (NOT just the last 2), one more Ctrl-Z reverses the second rename, and one more the first. That means that an undo step goes back to the last StartUndo (not EndUndo) that the programmer has set. Any nesting is ignored.

I did a few more nesting experiments but I'm not posting them here as they all point to the same behavior. I do not get any errors though, even if I completely botch the sequence - two StartUndo in a row, AddUndo before StartUndo, AddUndo after EndUndo... it actually still works, but with the little limitation that each StartUndo that I issue will break up the sequence and require a new Ctrl-Z to undo. (I am not going into full reverse engineering here now - it would be nice if the documentation could tell us how error cases and nesting are actually handled, though.)

That means that if you have commands that internally perform an Start/EndUndo, you will not be able to get out of the additional Ctrl-Z. Same, I guess, if you issue a StartUndo inside of a function that you wish to reuse (although that may be a problem more suitable for libraries).

You may argue that this is a design flaw. A nested Start/EndUndo could actually be treated like a single subcommand, with a Ctrl-Z working only on the highest level - which would revert the results of a functionality from the view of the outermost Start/EndUndo, while all nested Start/EndUndo pairs on lower levels do not affect the reversal (so you could use a CallCommand including its internal Undos without enforcing another Ctrl-Z in the end). I'm just not sure whether C4D could handle this conceptually, as it would be easy to lose yourself in a tree of Start/EndUndos throughout the program.

Anyway. Your best bet may actually be to skip the CallCommands if possible and perform the necessary change by yourself, so you have a better control over the Undo sequences.
Or you can issue a feature request for a CallCommand with an additional parameter that allows you to suppress the Start/EndUndos that are added internally.

@bentraje Meh, I just noticed my first code is not a good example because of what I later wrote. Since the top object of the created hierarchy is already determining the fate of the subobjects, the additional AddUndos have no true function. That does not make it wrong but it does not properly prove what I claim ;-)

Try the following:

import c4d

def create():
    cube = c4d.BaseObject(c4d.Ocube)
    doc.InsertObject(cube, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, cube)
    sphere = c4d.BaseObject(c4d.Osphere)
    doc.InsertObject(sphere, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, sphere)
    plat = c4d.BaseObject(c4d.Oplatonic)
    doc.InsertObject(plat, None, None)
    doc.AddUndo(c4d.UNDOTYPE_NEW, plat)
        
def main():
    doc.StartUndo()
    create()
    doc.EndUndo()
    c4d.EventAdd()

if __name__=='__main__':
    main()

Here, the three objects are created independently on top level, yet still all disappear with one CTRL-Z.

(And again, this is true for all types of AddUndo.)