Posts made by hSchoenberger

@ferdinand
Thanks for the update.

Ok, as far as I see it, we call the RenderDocument.
This one saves an output image that does not have OCIO applied.
Then we OCIO-transform the bmp that RenderDocument returns.
Then we copy the render settings the user has set for the output image.
And save the bmp to a file with the name name and settings....
not ideal...

Different question:
Which function does Commandline.exe execute to render frames?
Any plans to export this function to the python API?
Then we do not need to use the BMP workaround with RenderDocument()
nor the workaround to save the scene and use the render queue.

@ferdinand

It is a blocking render using Commandline.exe
Are these questions?

An information.
In reply to your statements "The advantage is that with a thread one can realize non-blocking rendering with it" and to use "CallCommand".

But when you start another Cinema 4D.exe, or CommandLine.exe, or c4dpy.exe on the same machine,
they would all have their own render queue.

But if a new instance of C4D does not use the same render queue settings, how does it come that the same render queue is availabIe if I restart C4D?
Thats what I mean. The render queue settings/items are not bound to the executable instance, they are bound to the user settings.
Which means the artist has to clear the render queue every time he starts C4D.
And he looses old items on C4D restart.
But that would be an issue on MacOS only.
And still better than wrong frames.

(not quite sure how you use the CommandLine in this context)
The only Python code which will run in a CommandLine are plugins

Yes, you did not offer to run scripts directly, therefore we have written a plugin.
Our plugin works for 11 years now, since C4D version R16.
(We still have to support older C4D versions as well, but perhaps we create some new connection with a version switch in the future. But for now adding other features is more important)

Renderings in themself are not blocking

I know, I am familiar with the multi-threading of renderers.

Your function doRender() has already implemented blocking.
So blocking is not an issue.

letting GPU render slaves run on a machine an artist is actively working on

I know. We are working with Redshift since the first beta version.
I did not mean that 2 GPUs jobs run at the same time.
(With the exception that we offer the option to split your GPUs if you have multiple installed)
But it can run at night.
And there are CPU renderer which can be assigned to some cores of the machine while an artist is working

Hi @ferdinand

It is a blocking render using Commandline.exe.
And it always output files to disk.

BatchRender would probably change the render queue items if C4D is started by an artist as well.
And the artist might use the render queue for testing/preview.
We can perhaps relink the user prefs folder on Windows, but not for MacOS.

On the other side, CallCommand is a wrapper to emulate a button click in the UI as far as I understand.
And the UI is not available in Commandline.exe.

We have to do some tests.

So, please let's start over here,

Ok, so can we now agree that we are both professional developers and we both both about OCIO.
And get back to the issue that our end customer wants to render frames via a script and not via UI functions.
But still get the same output file.

Hi

We will not go on wild goose hunts for bugs without clear instructions on what is not working and reproduction steps

At first, I just wanted to know if I am missing any flag/option in the script.
Of course I would have send you repro steps if it turns out to be a bug. But it got into a discussion not about how C4D works, more about how OCIO should work.

You actually have to cooperate with us

I am trying. But it is difficult.
You are telling me again and again that I do not know anything about OCIO!

Have you thought that what you stated might be slightly wrong?
e.g. your first statement that started the theory versus reality discussion:

A rendering does not contain the view transform, as this would basically be against everything OCIO is about

As I cannot argue with information. Simple Repro steps to show why I told you you are not 100% right:

• Open C4D, new scene.
• Add some object.
• Set a filename for "Regular Image", but keep all other settings to the default.
• Render to disk in any way.
• The View Transform is baked. And I have NOT enabled any setting. This is the default behavior of C4D. And you cannot disable it.

Cinema 4D is not baking in the view transform everywhere

As you can see in this example.

Back to the main issue "script versus other C4D functionality"
Reproduction steps:
250306_OcioScript.zip

1. Open the scene.

Render with Baked OCIO:
2) Execute "Render to Picture Viewer" (rename the output).
3) Execute "Add to Render Queue", start it (rename the output).
4) Render via commandline (rename the output).

Render without Baked OCIO:
5) Execute the script (rename the output).

Request:
No matter how C4D saves a rendered frame, the file written should always look the same.

refuse to read
which will also explain you what a view is

OK, If you want to hear it from me: The view transform was "invented" to mimic a different display type like a movie screen. This is done not only to have the option to export it for different devices, it is done to have a more physical correct compositing as well (linear space).
But - as I already stated - within your pipeline only (Your OCIO graph columns Texturing, Rendering, Editing).
Not for the final image (column Products).

About your OCIO knowledge:
Let me ask you a question about the OCIO graph you posted: In the third column "Editing" you see the last box states the render in ACEScg. A customer can not display an ACEScg image on his screen. Just try to upload an ACEScg image to Youtube, use it on any website, burn it on a blueray, ...
In your graph: The editing ACEScg box is linked into a "sRGB" and "DCI-P3" color space. How do you think ACEScg is converted into sRGB? You have to bake a transform into the final image.

continue with wild statements ("everything is broken")

That was a simple conclusion....
I never assumed that anyone thinks the right answer is "everything is broken" to the issue.... I simply showed you the alternatives.

Let me explain: You state that it does not make any sense that the view transform is baked into the frame. It is wrong to do that. It should never be applied. So such a behavior is a bug in your eyes. And I took this statement and refer to it as "broken".

BUT: C4D does that by default.
And you cannot disable it (for 8bit output).

And that gets to the conclusion:
A) Either C4D does it wrong since forever (bug/broken).
It should not bake the view transform.
B) C4D does it right.
There is a good reason C4D bakes the view transform.
Customers creates a new scene, renders it and the image saved is the same as he has seen in C4D.
And that leads to the fact that the script render does it wrong.

You did not even mention that you have one of the baking options enabled

I did not enable anything.
C4D default

Hi

Please read the docs I have linked to understand what OCIO is trying to do on a technical level.

I know the different levels of OCIO as I have already implemented OCIO via C++ into an application.
You are right AS LONG AS you are working within your pipeline, the view transform is applied in the display function of every application. E.g. In compositing like Nuke.
But once you render a final image which is not intended to be loaded in any other application afterwards (an image send to the client),
then view transform has to be applied.
And the customer I am working for uses C4D to render final images as well.
This is why they need the view transform baked into the rendered image.

It has nothing to do with exr files

Ok, then I correct: If you render 8bit files, then "Bake View Transform" is enabled by default internally.
And if you render 32bit, then you can choose to enable "Bake View Transform" or not.
Nevertheless it does not work for rendering a frame via script.

Showing RenderDocument sourced images in the Picture Viewer

I am not loading anything into the Picture Viewer.
I stated examples how you can render to a file with C4D.
I was refering to this menu option:

Support Procedures: Reporting Bugs & Crashes

Ok, then I have to report a bug that the "Bake View Transform" does not work with a scripted render.
I assumed there is some kind of undocumented option/flag missing for the script functions.
But as it seems OCIO was not tested for a script render and therefore it is a bug
I send you the customers scene file and rendered images.

Hi

this is working as intended I would say

The View Transform is applied everywhere else.
That is the issue. I cannot generate the same output as C4D with a script.
If I Batch render the scene via commandline or if I start to render the output files via the Picture Viewer.

So either everything else is broken
or it is just that this script render does not work the same way as all other file outputs in Cinema4D.
And I assume the Batch render and the Picture Viewer render work as customers expect it (otherwise you would have fixed it already).

If you render .exr files, then you have an option to "Bake View Transform".
If you render any other file format, this option is unchangeable and always activated (internally).
And for both output types it does not work to bake the View Transform into the file if I try it via script.

Hi

I am using these script lines to render an image:

bmp = c4d.bitmaps.MultipassBitmap(int(arg.width), int(arg.height), c4d.COLORMODE_RGB)
rflags = c4d.RENDERFLAGS_EXTERNAL | c4d.RENDERFLAGS_NODOCUMENTCLONE | c4d.RENDERFLAGS_SHOWERRORS
res = c4d.documents.RenderDocument(doc, rd.GetDataInstance(), bmp, rflags)

But this does not apply the view transform.
Am I missing something?

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