POV-Ray

Please see discussion in  FS#64 

Regarding the hardware & wall-clock: i do not find them useful. You cannot know if povray was not sharing the CPU with another big cruncher. And extracting hardware information might be non-portable & painful.
(Additionaly, what about a fake inside a Virtual Machine ? might turns out as a "proof" of very bad performance for povray. Not the kind of publicity one might wants.)

Input file & date (which one ? start or end ? what about continued image ?) seems ok.

Not necessarily for publishing purposes, but for keeping tracking of one's own changes.

Not strictly a duplicate, as #64 talks about non-visible image meta data, not information rendered to the image itself.

I think this in essence boils down to a request to make this kind of information available in SDL, so that it can be used e.g. to generate text objects. Obviously, render duration is a piece of information that cannot be made available at that time, while current time & date as well as input file name might be. (Current time & date might also be useful for seeding random generators.)

I guess there is a clear consensus among the dev team that any overlaying of text (or anything else, for that matter) after the render is a no-go. (As Bones might put it, "Dammit Jim, I'm a renderer, not a batch image post-processing suite!")

I mainly want the feature to keep track of the (mostly performance-related) effects of small changes, such as turning on radiosity and antialiasing or replacing a CSG object with a mesh. When I make changes to scenes I tend to save new copies as files with different suffixes, for instance from "scene_c" to "scene_d" to "scene_e". Keeping track of which file contains which changes can be a pain, and there's no way to go back and measure past performance statistics in scenes that were rendered days or weeks ago.

Maybe the shellout mechanism will help you with this. It'll be re-enabled in the next 3.7 beta I guess. Other than that, metadata in the output file header ( FS#64 ) would help you, too. For overlaying the data onto the rendered image you'll need to set up or find some framework to call POV-Ray, compute render time information, and post-process the images as needed - it's not going to happen in POV-Ray.

I didn't notice that Thorsten did indeed submit a change (#5025) to the codebase already. Should be in the next beta. I'll leave the request open as "100% complete" / "requires testing" until then.

Duh, I just found myself editing the wrong FlySpray entry...

Proposal with change #5170 (still subject to approval):
provide SDL with "input_file_name", a token replaced by a string which is the name of the input file of the scene; and a string returning function "now()".

now() can have a string parameter (but can also be used without; the parenthesis are mandatory anyway).
When provided with a string, its value is used for formatting the current local time. Formatting documentation is the one of strftime() C function. (LC_TIME is taken into account too, so "%x" "%X" and "%c" might be different from one system to another)
Without parameter (that's not 'now("")', but 'now()' ), the format is "%Y-%m-%d %T-%z"
You can get the number of second from Epoch with "%s" (and for other possibilities, have a look at the man page of strftime). (whatever can the Epoch be on your system)
The final string is limited to about 200 glyphs (or char), you should not need as much for a printable time.

Nothing can stop you anymore to put the input_file_name and the time of parse in your picture as text object(s), whatever the name of the main pov file.
For render-time, sorry, it's impossible to provide it before it has been done.
(Parse time become easy: a now() at the beginning, another at the end... you do the math!)

Hmm, this should not be a token but rather a declared value, which can also be passed from the frontend to the backend.

Having raw C syntax exposed in SDL is no good idea, assuming I understand your description of the proposed solution correctly.

I thought a long time about a declared value for input_file_name, but:

1. I failed to code it correctly (always got some error at runtime), despite trying at the same level as image_width & image_height (but they are int/float, that one is a string) (in vfe.cpp)
2. A declared value is subject to being updated by the scene file(s) & includes... which is on the subject of getting the filename of the scene seems useless and counter-productive. So coding it as a function that provide a string was also ideal: you cannot change the value, as it's a function.

About [Povray-] now(), it's not C syntax that is exposed, but the formatting string is provided to the internal [C-] strftime() which parse it and use it. It far better protected than [C-] printf().
(There is no memory overrun with strftime: if the resulting of the format string would exceed the size of the provided array, it just returns 0 and the string is undefined (well, I might need to amend the code for that, so far the result is untested, assuming success in all cases...).
For instance using ' now("Thorsten") ' is valid and provide only the string "Thorsten"
Why redefine a syntax & write a specific parser when the job is already done with strftime ? Especially when strftime has been available in SystemVr4, C89, C99 and al. with a stable interface about its parameters.
(I won't say so of things like gettimeofday() across various systems)

I propose to slightly modify the mechanism a bit:

• add a predefined value "now", holding the current (GMT) time as a Unix timestamp (start of parsing);
• change the "now()" function to "datetime()" (or something similar), passing both a unix timestamp and an (optional) format string.

This would have the added benefit that...

• "now" could also be used to seed random number generators if desired (using "seed(now)") - a feature that is occasionally requested as well;
• it would allow the user to do arbitrary custom computations on the time if they really desire so (e.g. feed the information into a slightly adapted sunpos.inc, or use it to control the position of the planets in a solar systm model, or whatever, e.g. to automatically render hourly wallpapers, do some fancy stuff with live webcam feeds, or whatever crazy idea people might think of);
• likewise, it would allow the user to compute dates for non-gregorian calendars (jewish or islamic calendar for instance);
• it would make life easier in case we decided to add other time-related features, e.g. retrieving the last modification time of the file being parsed, or even the last modification time of an arbitrary file;
• in that case it would also make time computations easier.

If you want to make now() return a numerical value and add datetime() please do so today.

Done. Change #5271

Can the timestamp be appended to the file name of the output image too?