Resolving Save Path in Render Settings

a_block

Hi,

it's this time again, I'm not seeing the forest for the trees.

Lets assume, we have an arbitrary project file with arbitrary render settings.
Is there a way to get the resolved Save Path?

There are so many things going on there:

Tokens
Filename absolute/relative
File suffix of output format being added (possibly removing manually entered suffix, like .tiff ending up as .tif and not .tiff.tif as I would have suspected)
Frame numbers being appended, based on frame range settings and number format settings and then in some cases suppressing the format suffix
and probably more I haven't thought of, yet

I agree, neither of these points requires any magic.
But I am certain, writing all of this on my own is almost guaranteed to deliver different results in certain corner cases. Let alone future changes in supported output formats or other changes on Maxon's side in this path handling, which would make the manual approach extremely error prone.

I would very much like to hear, that I overlooked a tiny, sweet helper function maybe in utils or maybe a cute little message to retrieve the resolved path. That would be awesome.

Setting a different defined path from my side or even doing any renders to check for resulting filenames is not an option.

Cheers,
Andreas

ferdinand

Hello @a_block,

thank you for reaching out to us and please excuse the short delay. The task of answering your topic had to be reassigned internally, causing the delay.

There is unfortunately no helpful answer to your question. I would even go further than you did in your question and reject the statement that "neither of these points requires any magic", implying a laborious but trivial task. You overlooked multipass information and the fact that there can be render tokens plugins which rely on render time information as for example the active take or light ids. One could technically call these plugin render tokens manually but reproducing the render time information will be almost impossible.

I have read that you do not want to launch a render, but that is effectively the only way I would see to achieve your goals to a certain degree. I would have to try myself, but the RenderData of a rendering document are already preprocessed, i.e., they differ in a few points from the RenderData of the associated document which launched the render. You could try to launch a render, then intercept MSG_MULTI_RENDERNOTIFICATION in some node data plugin (which will also be emitted before the rendering actually started) and check in the associated render data if the rendering path has already been resolved (it is very likely that this is not yet the case at that early point). The remaining solution would be to render the document at a 1*1px size, to cut down the rendering times at least partially.

But I personally would not dig down any of these paths and rather write something simplistic myself, guessing the output paths, and accepting the limitations of the approach. I would also ask myself if your problem can be restated, e.g., instead of knowing and storing the absolute paths, one could write something which stores a pattern with which one can determine if an existing file on disk is associated as a rendering output with the given document for which the pattern has been stored. But the feasibility of this depends on what you want to do exactly.

Cheers,
Ferdinand

a_block

Hi Ferdinand,
thanks for your thorough and detailed reply.

The problem is, I need to put the correct name of the rendered output into a text file. This needs to match, when rendered later on. So, just guessing something similar is also not an option.

I already anticipated, there would be no easy solution.

By the way, even if I had the time to test render 1x1 images, it would still not be ok, there are resolution tokens...

I will most likely reduce the amount of freedom the user has here, in order to end with something deterministic.
Thanks for your help and ideas. You can consider this topic closed from my side.

Cheers to the entire SDK Team,
Andreas