Posts made by hSchoenberger

@Dunhou
I am sorry, but your module uses the exact same code as I have already posted as NOT working (for all cases).
You are reading the information from the document, not the installed plugin.

@ferdinand said in Get information about renderer plugin via Python:

your question is off topic for the forum you have posted in.

Sorry, but this is a C4D SDK question!
It is NOT about the Octane SDK.

"How can I list all installed renderer plugins in C4D with their version?"

Plugins have to provide informations for RegisterVideoPostPlugin().
Like the name and a disklevel (which might or might not set to the same as the plugin version),
I though I can access this information.

There is no (publicly available) standardized interface with which plugins or specifically renderer plugins would store their version.

Ok, I assumed that C4D works just like e.g. the plugin manager in Maya.
Which is able to list the version of each plugin.

And as I have found some script for a probbaly old C4D versions, I assumed there is still a way to do that with the latest version.

plugins = c4d.plugins.GetFirstPlugin()
    while plugins:
        print("Name:", plugins.GetName())
        print("ID:", plugins.GetID())
        if plugins.GetPluginType() == c4d.PLUGINTYPE_SCENESAVER or plugins.GetPluginType() == c4d.PLUGINTYPE_SCENELOADER:
            print("Version:", plugins.GetFileVersion())
        else:
            print("Version:", plugins.GetVersion())
        print("\n")
        plugins = plugins.GetNext()

Hi

Is there any way to get some information about renderer plugins?
I want to get the version of the Octane plugin.

Background:
All I have found was a script snipplet to get some information from a data block inside the C4D document.

doc = c4d.documents.GetActiveDocument()
bc = doc[ID_OCTANE_LIVEPLUGIN] 
print ("Octane version=",bc[c4d.SET_OCTANE_VERSION])

But this might not be the version that is currently used, it can be the version that was used to create/save the scene.

So how I can loop through all plugins loaded and get some information from the plugins like the version?

Any update?

Hi

Issue 1 (default.profraw file):
Yes, it is a compiler settings. The setting was set in R20 as well, the setting was probably never checked/noticed since the affected module was created.
The Solidangle developer has fixed the issue in Arnold4C4D by "My workaround is to look for and remove the file from cwd in PluginStart() and change cwd to /var/tmp on PluginEnd(). This means the file is not in the folder where C4D was started from nor the project folder, only in /var/tmp which is acceptable."
Which means that if I "cd /var/tmp" before starting C4D, the message should be gone.
I have not yet tested it as R20 has the same issue and still renders.

@r_gigante
PS: Remember that R20 has the same error messages, but still renders.
It is an issue that does not print any error messsage, but calls an exit(0) or a return(0) in your main.cpp.
(No error code used in return() or exit())

OR: It prints it, but a flush command is missing after the last print command.
And closing the app might loose the log buffer that was not yet transfered to the systems log pipe.
(We had that issue with Maya crashes, the last lines of the stack trace Maya prints had been missing)

@r_gigante

Hi

Windows:
So far we do not see any issue on Windows. Perhaps ther is a difference in the service environment compared to your test environment. Our service tells Windows to load a users environment (Registry, C:\Users...)
There is an openGL error message, but it has no effect:

Could not initialize OpenGL root context: unsupportedoperation [ogl_context_win.cpp(1176)]

Licensing:
A customer had that issue some time ago and their error message was clear about the missing license setup.
I have set g_licenseusername and g_licensepassword In my test environment.
If I block Commandline from accessing the Internet on Windows via a firewall, I get a license error message as well.
I have tested to use a wrong g_licensepassword. Windows reports "Invalid License".
OSX does not get to that part, same behavior as usual.

Daemon:
Our render manager Royal Render handles the daemon part and then starts a shell script with the C4D commandline executable. File /Library/LaunchDaemons/de.BinaryAlchemy.plist attached:de.BinaryAlchemy.rrAutostartservice.plist.txt

I have some render logs.
Note: If a line starts with "StdErr:", then your app printed it into the StdErr insted of StdLog. StdErr and StdLog might be a bit async due to the systems log pipe.
Mac just started, no user logged in: WindowServer_NeverInitialized.txt
User logged in:
WindowServer_LoggedIn.txt

PS:
I can provide you a simple Daemon that just executes a shell script over and over without all the other files that Royal Render uses. The deamon has its own installer included (for the /Library/LaunchDaemons/de.BinaryAlchemy.plist file).
OSX and Windows.

Or a full RR demo that gives you more control about when to start a render commandline and it saves render log files for each render. Or you can use our test machine via teamviewer.

Hi

I already contacted support about the issue and they told be to use the SDK forum to get in contact with the development team about this issue. The issue is that R21 cannot be used any more within a background deamon(service) on macOS. One of our customers just switched to R21 for their upcoming project and they got into that issue.

If you need help to reproduce the issue or a test machine (teamviewer) to test something, please let me know.
Or if you have any test application/ test version you would like me to run, let me know as well.
Perhaps a version that prints every step helps you to find the location/module that is responsible.
E.g. Loading module "asdsdas" now, Initializing "asdsdsa".

About running as background deamon(service):
Many companies require security rules like that everyone has to logout if they leave or that the user logged-in is not allowed to access all projects that the render farm can access. Therefore the render farm has to run as background service/deamon. I was already told by support "I would not be aware that our software can even be used without a logged-in user". BUT: Even if you have not tested it, companies use it and HAVE TO use it.

I can not tell you the exact issue why R21 does not run, I have just collected some issues I found.
BUT: these errors have been printed by R20 as well, but R20 rendered anyway.

Issue 1:
The last message that is printed is "LLVM Profile Error: Failed to write file 'default.profraw': Permission denied".
R20 prints the same message when the app is closed (after the render).
There is an other issue with the file as well, customers report that these files are big and if you use Arnold, they are saved beside the scene. Solidangle (Arnold renderer) has already told me that the issue of that file is in the C4D python lib: "The default.profraw file is created in the current working directory when Cinema 4D starts and written when Cinema 4D closes."

Issue 2:
If the mac was restarted and nobody ever logged in, then the last error is
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
2020-02-06 15:08:36.947 Commandline[477:3391] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'ClientCallsAuxiliary': Connection interrupted

Issue 3:
The Commandline app tries to load many libs that require an UI. Shouldn't the Commandline app be able to run without UI libs? It prints about 150.000 bytes of warning messages each time started.
Examples:
net.maxon.gui: Initialization of mac_clipboard.mm [initialization] failed.
net.maxon.drawport_opengl:....
net.maxon.c4d.c4dplugin: paint_tooltransrect.cpp
net.maxon.mvp_base_presenter: presenter_base_impl.cpp
net.maxon.mvp_base_view: widget_base_impl.cpp
net.maxon.mvp_desktop2d_widgets
net.maxon.c4d.nbp: nimbus_impl.cpp could not be initialized because net.maxon.interface.amemulation is missing.
net.maxon.c4d.nodeeditor_material: could not be initialized because net.maxon.mvp.windowclasses.base is missing.