Sorry for barging in, but as the same Q was asked on two more forums, I stumbled over it.

I couldn't find the actual error in the code, but after reducing the whole thing to the crucial lines, I am fairly convinced that it is a bug. I created a completely new scene (R21) to exclude any strangenesses from the original file, and it's still easily reproductible:

The script here is very simple:

import c4d

def main():
    obj = op.GetObject()
    parent = obj.GetUp()
    parentMat = parent.GetMg()
    obj.SetMl(~parentMat)

It does nothing but assign the child the inverted parent matrix as local matrix. Logically, this should make the child stay constant and in place, regardless of whatever changes you perform to the parent.

It works very well as long as you only rotate or translate the parent; as soon as you add some scaling, you get the result above. The child's matrix starts shearing, and the coordinate system is no longer orthogonal (which isn't even supported by C4D natively).

I can only conclude that the matrix inversion has a bug and is not handling scaled matrices correctly (as strange as it sounds - such a basic error should show up in every second scene...).

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.

@zipit said in How to enforce StatusBar redraws:

c4d.gui.GeUpdateUI()

Nope, that doesn't work reliably either. It's definitely a question of how the message loops are forwarding messages to each other, and how the status bar is updated internally, and how the windows are parented to each other. Without the C4D source code, it's probably impossible to come to a definitive answer.

Here's what I checked:

1. Script Manager and Status Bar are both docked in the main window. Works.
2. Script Manager and Status Bar are both docked in the Independent Window. Works.
3. Script Manager and Status Bar are both docked in the Dependent Window. Works.
4. Script Manager is undocked, and the Status Bar is docked within that window. Works. Though, that may be the same case as 2/3.

As long as Status Bar and Script Manager share a MS Windows window, the update message is apparently propagated and the Bar progresses. This works even if I use a keyboard shortcut to start the script while the main window/viewport is the active window.

5. Script Manager is docked in the Independent Window, and Status Bar is docked there too but then I undock the Status Bar. Works. (Seems the undocked Status Bar is internally still a child of the Independent Window.)
6. Script Manager is docked in the Independent Window, and Status Bar is docked in the Main Window; then I undock the Status Bar. Doesn't work. (While this seems the same as 5, here the Status Bar seems to stay a child of the Main Window.)
7. Script Manager is docked in the (In)dependent Window, and Status Bar is docked in the Main Window. Doesn't work.
8. Like 7 but vice versa. Doesn't work.

I gather that while the Python interpreter is running, the Script Manager still has some update loop running (not a normal message loop, as you can't move the window edit any code there) that is taking care of the status bar updates when in the same window (hierarchy?).

I also suppose that the status bar gets some exceptional updates, as the Console never updates (I tried to insert some print commands into the timer loop) before the script ends, regardless of the window hierarchy.

Okay, that was enlightening, thanks for the comments. I suppose Maxon needs to expand the status bar updates across the whole window hierarchy, so the bar would work everywhere, but I also have a feeling that they won't bother with such a minor issue

@zipit Thanks, but this doesn't work in my setup. What happens (on my system at least) is that an empty dialog appears. The status bar still doesn't update before the Python script ends.

I found that it does work if I dock the status bar in the same window as the script manager (I do not need the separate dialog in that case), so obviously it depends on what internal message loop is still evaluated and which one is blocked.

Normally my status bar resides in a separate window on the second screen (together with material manager, Takes manager and other stuff) which is classed as "Independent Window" (the latter doesn't matter for the message loop apparently, if the window is not independent, it doesn't work either).

There is no documentation on how the windows' various message loops interplay with the Python interpreter (beyond the obvious modal dialogs), but what I experimentally find, baffles me a little.

Hello again;

when I wish to use the global status bar in Python (c4d.StatusSetBar() etc) I need to relinquish control to C4D so the GUI can be updated and the status bar is actually redrawn. If I'm in a Python script and just keep setting the status bar, it's only updated after the script has ended:

    for p in xrange(101):
        c4d.StatusSetBar(p)
        time.sleep(0.05)

So, this code obviously doesn't work.
Adding EventAdd() doesn't work either, as this will only add a redraw to the message queue, which is not evaluated until the script ends.
Using c4d.GeSyncMessage(c4d.EVMSG_CHANGE) seems promising but it always returns False.
DrawViews only redraws the viewports.

Is it really impossible to relinquish control from a Python script to enable C4D to evaluate the message queue once, and then return to the script? Or enforce the update of the status bar in some other way? It's definitely not an insurmountable technical issue, because if I call MessageDialog in between...

    for p in xrange(101):
        c4d.StatusSetBar(p)
        if p in [5,20,30,40,50,75,100]:
            gui.MessageDialog("xxx")
        time.sleep(0.05)

...not only the dialog appears, but also the status bar is updated. And the really strange effect: The status bar seems to update distinctly several times between message dialogs at some points. Try [0,100] as timing for the dialogs to appear... what's causing these intermediate updates? Why doesn't that work without the dialog calls?

(We do not need to discuss calling the status bar updates in asynchronous worker threads or through the message system; I just want to know whether there is a way to call it from a script, and to solve the dialog riddle...)

@zipit okaaaay I get it: you NEVER EVER sleep!

@curripod00 said in Connecting Camera Focus Distance to Null Object with Python:

camera[c4d.CAMERAOBJECT_TARGETOBJECT] = null

This line cannot work because "null" is an undefined variable name (and "camera" actually too). It references nothing.
Instead, you will need to find the actual target null by searching:

camera = doc.SearchObject("Camera")
camera[c4d.CAMERAOBJECT_TARGETOBJECT] = doc.SearchObject("Camera_Target")

(I did not test that, just slapped together from memory.)

This is still not very good code because it assumes that the new camera's name is "Camera" which is not very original and may be duplicate in the scene already. Feel free to call the camera something else by setting the name when you generate the object.

Or instead of searching, you store the objects after generation in a variable. Following code should do it (I didn't test, as I don't have Redshift):

import c4d
from c4d import gui

def main():
    def object():
        return doc.GetActiveObject()
    def tag():
        return doc.GetActiveTag()

    c4d.CallCommand(5140) # Create Camera Targeting Null
    cameraTarget = object()
    cameraTarget[c4d.NULLOBJECT_DISPLAY] = 13
    cameraTarget[c4d.NULLOBJECT_RADIUS] = 80
    cameraTarget[c4d.ID_BASEOBJECT_REL_POSITION,c4d.VECTOR_Y] = 276
    cameraTarget[c4d.ID_BASELIST_NAME] = "Camera_Target"

    c4d.CallCommand(5103) # Create Camera with Redshift Tag
    camera = object()
    camera[c4d.ID_BASEOBJECT_REL_ROTATION,c4d.VECTOR_X] = 0
    camera[c4d.ID_BASEOBJECT_REL_ROTATION,c4d.VECTOR_Y] = -0.175
    camera[c4d.ID_BASEOBJECT_REL_ROTATION,c4d.VECTOR_Z] = 0
    camera[c4d.ID_BASEOBJECT_REL_POSITION,c4d.VECTOR_X] = 0
    camera[c4d.ID_BASEOBJECT_REL_POSITION,c4d.VECTOR_Y] = 433
    camera[c4d.ID_BASEOBJECT_REL_POSITION,c4d.VECTOR_Z] = -884
    c4d.CallCommand(100004788, 50075) # New Tag
    cameratag = tag()
    cameratag[c4d.REDSHIFT_POSTEFFECTS_DOF_OVERRIDE] = True
    cameratag[c4d.REDSHIFT_POSTEFFECTS_DOF_ENABLED] = True
    cameratag[c4d.REDSHIFT_POSTEFFECTS_DOF_RADIUS] = 8.5

    camera[c4d.CAMERAOBJECT_TARGETOBJECT] = cameraTarget

if __name__=='__main__':
    main()
    c4d.EventAdd()

Learn more about Python for C4D scripting:
https://www.patreon.com/cairyn

I was curious and just tried c4d.CallCommand(12104) - it does close the GUI app even from a Python script. (And asks for unsaved content too; I suppose it won't close if you cancel but I didn't check that.)

@m_adam Thanks for the confirmation!

(I swear I'm not doing this on purpose...)

I was just playing with the render tokens in Python, and I found some strange behavior in the example py_render_token_r21.

I modified the code a little to give me three different render tokens but the PythonFrameToken function should work the same as the Maxon original. I just added a test for NOTOK here:

import c4d, time

def PythonFrameToken(data):
    """
        data[4],  # The frame number used for rendering or NOTOK if the frame is not yet recognized.
    """

    print "Token $PythonTokenFrm replaced:", str(data[4]), data[4]
    if data[4] == c4d.NOTOK:
        return "NOTOK"
    else:
        return str(data[4])

   
def PythonTimeToken(data):
    return time.strftime("%a in %B") # Weekday in Month
   
    
def PythonFirstObjectToken(data):
    obj = data[0].GetFirstObject()
    if obj == None:
        return "None"
    else:
        return obj.GetName()

            
if __name__=="__main__":
    for registeredToken in c4d.modules.tokensystem.GetAllTokenEntries():
        print registeredToken
        if registeredToken.get("_token") in ["PythonTokenFrm", "PythonTokenTime", "PythonTokenFirstObject"]:
            exit()

    c4d.plugins.RegisterToken("PythonTokenFrm", "This Python Token shows the frame", "001", PythonFrameToken)

    c4d.plugins.RegisterToken("PythonTokenTime", "This Python Token shows the time", "Sat in June", PythonTimeToken)

    c4d.plugins.RegisterToken("PythonTokenFirstObject", "This Python Token shows the name of the first object", "MyObject", PythonFirstObjectToken)

(I am aware of the problem described here:
https://plugincafe.maxon.net/topic/12162/custom-tokens-with-team-render-server
so I know this may not work on TeamRender, but I'm working on full GUI C4D so this does not apply.)

And here's the issue:
The function PythonFrameToken returns NOTOK in the crucial call. So, the file name ultimately contains "NOTOK" instead of the actual frame number.
The other two tokens work fine as expected.

Looking at the console output, PythonFrameToken is called several times; here rendering frame 15-16:

Token $PythonTokenFrm replaced: -1 -1
Token $PythonTokenFrm replaced: -1 -1
Token $PythonTokenFrm replaced: -1 -1
Token $PythonTokenFrm replaced: 15 15
Token $PythonTokenFrm replaced: -100000000 -100000000
Token $PythonTokenFrm replaced: 15 15
Token $PythonTokenFrm replaced: -100000000 -100000000
Token $PythonTokenFrm replaced: 15 15
Token $PythonTokenFrm replaced: 15 15
Token $PythonTokenFrm replaced: -100000000 -100000000
Token $PythonTokenFrm replaced: 16 16
Token $PythonTokenFrm replaced: -100000000 -100000000
Token $PythonTokenFrm replaced: 16 16
Token $PythonTokenFrm replaced: 16 16

At some point, data[4] obviously yields the correct value, but the filenames are still wrong.
It does not matter whether the path string contains a path or just a filename without path component.

This comes from an official example for R21 though - so I wonder what's wrong.