Just wanted to mention, the docs don't mention output after you begin mentioning animations (for example commands), but output directory must be set to run the render (not a filename), which is not part of the commands, so they all error out.
Actually unsure how naming conventions works. Setting a output folder and TG uses the output folder as a filename. So I gave it a base filename to start with.
Oh I see you use OX. However, it's not saving anything when doing OX.
Extra output filename (-ox) = /home/was/Terragen/out/bga.tiff
Frame list (-f) = 1 2 3 4 5 6 7 8 9 10
Cannot create the output file path.
Extra output filename (-ox) = /home/was/Terragen/out/bga.%04d.tiff
Frame list (-f) = 1 2 3 4 5 6 7 8 9 10
Cannot create the output file path.
Above directory is writeable, and single frames save just fine.
Also notice it mentioned the project path from Windows, and tries to add frame numbers? Confusing. This is Linux.
The path is: C:\Users\WAS\Documents\Background_Galaxy_Anim.%04d.tif
Destroying trPrivateGlobals
It's very odd that the node would allow you to render with -o when you have frames specified, and just continually overwrite the same file.
Update: Did figure out that the frame/image number (%04d) can be assigned to the -o output, which solves my issue. Though curious why alphas etc won't export.
Hi WAS,
Now that you've solved some of the issues and made edits to the post, I'm a bit confused about which questions are still active. Can you summarize the remaining problem(s) you need help with?
Quote from: Matt on December 27, 2019, 07:19:25 AMHi WAS,
Now that you've solved some of the issues and made edits to the post, I'm a bit confused about which questions are still active. Can you summarize the remaining problem(s) you need help with?
Only thing I'm super confused about is OX feature is saying it can't save in the output dir for some reason (where everything outputs), and I'm puzzled why doing a frame render it would let you overwrite the same file over and over. It is cool we can just use unix codes for stuff like 0s and numerics but perhaps that sort of functionality should be automatic. Do people really need to be using special numeric entries when most sequencers allow you to fine tune for filenames such as preceeding 0s? Also in Linux unless a flag is used to overwrite, you shouldn't overwrite anything and prompt.
Also puzzled why it's trying to use a Windows path from my PC on Linux. What's that about?
Quote from: WAS on December 27, 2019, 10:26:34 AMOnly thing I'm super confused about is OX feature is saying it can't save in the output dir for some reason (where everything outputs)... Also puzzled why it's trying to use a Windows path from my PC on Linux. What's that about?
Can you send me the full log, and the command line?
Default behaviour comes from the TGD file, including the file paths. The Windows path must be coming from your TGD file. If it's the main image, -o will override this. If it's the "extra output images" (alpha and/or render elements), then -ox should override it. If your TGD has extra output images enabled, you need to specify both -o and -ox paths on the command line if you don't want it to use paths in the TGD file.
Quoteand I'm puzzled why doing a frame render it would let you overwrite the same file over and over
The command line renderer is mainly intended to be used in an automated/scripted environment and it doesn't have an interactive mode to handle exceptions, so it writes to any filename you tell it to, even if that means overwriting something from a previous run.
QuoteIt is cool we can just use unix codes for stuff like 0s and numerics but perhaps that sort of functionality should be automatic. Do people really need to be using special numeric entries when most sequencers allow you to fine tune for filenames such as preceeding 0s?
Perhaps the syntax could be nicer. What do you mean by automatic?
Quote from: Matt on December 30, 2019, 04:24:23 PMCan you send me the full log, and the command line?
Yeah when the machine is clear I can get one.
Edit: Does the -OX feature
require imagetype?
Quote from: Matt on December 30, 2019, 04:24:23 PMDefault behaviour comes from the TGD file, including the file paths. The Windows path must be coming from your TGD file. If it's the main image, -o will override this. If it's the "extra output images" (alpha and/or render elements), then -ox should override it. If your TGD has extra output images enabled, you need to specify both -o and -ox paths on the command line if you don't want it to use paths in the TGD file.
That makes sense. It was showing the correct paths before this with the -OX error, and was only showing (that I recall) with the -OX feature, but at the very end after the main error about not being able to save. So may be nothing.
Quote from: Matt on December 30, 2019, 04:24:23 PMQuote from: undefinedIt is cool we can just use unix codes for stuff like 0s and numerics but perhaps that sort of functionality should be automatic. Do people really need to be using special numeric entries when most sequencers allow you to fine tune for filenames such as preceeding 0s?
Perhaps the syntax could be nicer. What do you mean by automatic?
I feel you could just have a -d flag and number of preceeding 0s, and the renderer script could just automatically append. It is nice being able to manually setup the file names and stuff but could also have a default raw behavior to handle frames.
Edit: Same for image types. They could just be apprended by default if not defined.
Quote from: WAS on December 30, 2019, 06:27:15 PMEdit: Does the -OX feature require imagetype?
No, it doesn't require it. It's included in the default filename to avoid clashes in case you output more than one render element, but even then it isn't necessary if "create subfolders" is enabled (which can also be overridden from the command line).
By the way, other variables can be used in filenames since 4.4.18, and they work with -o and -ox arguments too.
https://planetside.co.uk/wiki/index.php?title=Render_Node_(TG4)#Sequence.2FOutput_Tab
Hmm. Well that puts an end to the thought I had. I'm not sure why it's doing it then. The only thing that differed from the commands was "X" in -OX. Once I can login to my server (i forgot to set 20 threads instead of 24 again, so CPU is too busy for SSH) I'll get a full console log.
By the way though, the path The path is: C:\Users\WAS\Documents\Background_Galaxy_Anim.%04d.tif Is not where that file is stored, and no TG files are ever stored there. So it's very confusing. Everything, and it, is stored in D:\Terragen\Projects\Atmosphere. It created that path itself it seems.
Additionally, the filename set was bga-%04d.tif and it seemed to have just ignored that and done the project filename.
I'm sure there will be a good reason once we see the logs and the command line.
Quote from: WAS on December 30, 2019, 08:30:01 PMBy the way though, the path
The path is: C:\Users\WAS\Documents\Background_Galaxy_Anim.%04d.tif Is not where that file is stored, and no TG files are ever stored there. So it's very confusing. Everything, and it, is stored in D:\Terragen\Projects\Atmosphere. It created that path itself it seems.
Additionally, the filename set was bga-%04d.tif and it seemed to have just ignored that and done the project filename.
And this?
<<<### APP RUN STARTED ###>>>
Terragen 4 build 4.4.46.frontier
Licensed to Jordan Thompson
Receiving maintenance until 2020-08-13
Maintenance days remaining: 225
No EDD key
License key file: Set by an administrator
Found license for Professional Edition
Found 24 processor cores
Using 24 processor cores
Loading plugins in: /home/was/Terragen/TG44461/
No files matching *.tgp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/plugins/
Loaded 3 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/plugins/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/
No files matching *.tgp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/linux_intel/
No files matching *.tgp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/linux_intel/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loaded a total of 3 plugin modules
ReadXML: Attempting to read file: "/home/was/Terragen/Projects/Background_Galaxy.tgd"
ReadXML: done
Content path for children of "_1" set to "/home/was/Terragen/Projects/"
Starting render...
Extra output filename (-ox) = /home/was/Terragen/out/Background_Animation.tif
No -f specified, so rendering the project's current frame
Cannot create the output file path.
The path is: C:\Users\WAS\Documents\Background_Galaxy.%04d.tif
./terragen -p /home/was/Terragen/Projects/Background_Galaxy.tgd -exit -r -ox /home/was/Terragen/out/
<<<### APP RUN STARTED ###>>>
Terragen 4 build 4.4.46.frontier
Licensed to Jordan Thompson
Receiving maintenance until 2020-08-13
Maintenance days remaining: 225
No EDD key
License key file: Set by an administrator
Found license for Professional Edition
Found 24 processor cores
Using 24 processor cores
Loading plugins in: /home/was/Terragen/TG44461/
No files matching *.tgp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/plugins/
Loaded 3 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/plugins/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/
No files matching *.tgp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/linux_intel/
No files matching *.tgp in this directory
Loaded 0 modules in this directory
Loading plugins in: /home/was/Terragen/TG44461/../../tgdplugins/linux_intel/
No files matching *.cpp in this directory
Loaded 0 modules in this directory
Loaded a total of 3 plugin modules
ReadXML: Attempting to read file: "/home/was/Terragen/Projects/Background_Galaxy.tgd"
ReadXML: done
Content path for children of "_1" set to "/home/was/Terragen/Projects/"
Starting render...
Extra output filename (-ox) = /home/was/Terragen/out/
No -f specified, so rendering the project's current frame
Cannot create the output file path.
The path is: C:\Users\WAS\Documents\Background_Galaxy.%04d.tif
Destroying trPrivateGlobals
Did a few tests always the same. Still not sure how seeing the whole console would help considering it's a an error at the end.
It appears that you haven't used the -o switch to set the output file path, so it uses the file path that was set in the TGD (C:\Users\WAS\Documents\Background_Galaxy.%04d.tif). Since this isn't a valid path on your Linux machine, it prints the error "Cannot create the output file path" followed by the path that produced the error.
-o overrides the path and filename for the main image.
-ox overrides the path and filename for Extra Output Images (Render Elements).
If your project outputs both types of images, you need to specify both on the command line (unless you want it to use the values from the TGD file).
-o and -ox should be followed by the path to the file including the filename, not just the folder.
Quote from: Matt on January 02, 2020, 11:48:20 AMIt appears that you haven't used the -o switch to set the output file path, so it uses the file path that was set in the TGD (C:\Users\WAS\Documents\Background_Galaxy.%04d.tif). Since this isn't a valid path on your Linux machine, it prints the error "Cannot create the output file path" followed by the path that produced the error.
-o overrides the path and filename for the main image.
-ox overrides the path and filename for Extra Output Images (Render Elements).
If your project outputs both types of images, you need to specify both on the command line (unless you want it to use the values from the TGD file).
-o and -ox should be followed by the path to the file including the filename, not just the folder.
Really now? Documentation doesn't indicate this. It gives you single case examples. -ox or -o, and explains them as the same thing minus image type definition for different filetypes. Which gives the impression you use one or the other, and really could be the same command with switches based on detection of image types for extra output.
Also why is this path being set in the TGD when it's not even its location, nothing is ever saved there. Raw documents root? Lol. TG is fabricating this path.
If it's going to be coming up with paths it should be where the TGD is actually saved. Additionally being Linux it should be falling back on Linux tmp or any path specified (like -o).
Linux docs need to show full examples, not things looking like commands but broken up and not going to work....and no explanation to the effect
Here's an example of a complete command line that does the following:
- renders frame 42
- overrides the filename for the main output to /home/was/Terragen/out/Background_Animation.%04d.tif
- overrides the filename for the extra output images to /home/was/Terragen/out/Background_Animation.IMAGETYPE.%04d.tif
./terragen -p /home/was/Terragen/Projects/Background_Galaxy.tgd -exit -r -f 42 -o /home/was/Terragen/out/Background_Animation.%04d.tif -ox /home/was/Terragen/out/Background_Animation.IMAGETYPE.%04d.tif
Other possibilities for these switches are documented here: https://planetside.co.uk/wiki/index.php?title=Command_Line_Reference
-o and -ox are overrides. When not present in the command line, output filenames are derived from the render node in the project file:
(https://planetside.co.uk/wiki/images/e/ee/Render_SequenceOutputTab_2019-09-27.02.png)
Additional documentation is in the Wiki here: https://planetside.co.uk/wiki/index.php?title=Render_Node_(TG4)#Sequence.2FOutput_Tab
This might be a useful excerpt:
Quote from: undefinedSettings
Output image filename: This is the filename of the main image that is saved to disk when you use "Render All To Disk", "Render Sequence" or render from a command line. This may be overridden on the command line (using the -o command), but if it isn't overridden then Terragen will use this filename. If you are using a render farm or render manager it might override this filename.
Extra output images: The checkbox enables the output of additional Render Elements, or, if no render elements are rendered it outputs an alpha image. This applies when using "Render All To Disk", "Render Sequence" or rendering from a command line. This may be overridden on the command line (using the -ox command), but if it isn't overridden then Terragen will use this filename. If you are using a render farm or render manager it might override this filename. The word 'IMAGETYPE' (not including quotes) needs to be included somewhere in the filename if you want each render element to have a distinct filename. 'IMAGETYPE' is replaced by a word that represents the name of the render element. A list of these element names can be found here.
According to the Linux Command Line docs (https://planetside.co.uk/wiki/index.php?title=Linux_Command_Line_Reference):
Quote from: undefined-o <filename>
Set the renderer's output image filename to <filename> before rendering. C-style format strings can be used to automatically insert the frame number, eg. '~/frames/image.%04d.IMAGETYPE.exr' Supported image extensions are .bmp, .rgb, .sgi, .exr, .tif, .tiff
-ox <filename>
Set the renderer's "extra output images" filename to <filename> before rendering. Extra output images should contain the string "IMAGETYPE" (not including quotes). When a render element is written, "IMAGETYPE" is automatically replaced by the name of the element. By default the only element is "tgAlpha", but additional elements can be enabled using a Render Layer.
For example:
'~/frames/image.0023.IMAGETYPE.exr'
may result in:
'~/frames/image.0023.tgAlpha.exr'
'~/frames/image.0023.tgSurfRgb.exr'
'~/frames/image.0023.tgSurfAlpha.exr'
etc.
or, if "create subfolders" option is enabled (in project or command line), may result in:
'~/frames/tgAlpha/image.0023.tgAlpha.exr'
'~/frames/tgSurfRgb/image.0023.tgSurfRgb.exr'
'~/frames/tgSurfAlpha/image.0023.tgSurfAlpha.exr'
etc.
C-style format strings can be used to automatically insert the frame number. Example:
'~/frames/image.%04d.IMAGETYPE.exr'
Supported image extensions are .bmp, .rgb, .sgi, .exr, .tif, .tiff
Unfortunately these long lines in the quotes are being clipped in the forum "light theme", but they are fine in the dark theme. I should be able to fix that.
Annnnd you don't see the problem here? You are requiring Linux paths (or it saves in the nodes folder) so it's not really just setting a filename. It's the location of the file and name... Additionally, for some strange reason they're separate commands which could be the same command, just looking for special names or not. If special names use for image types go ahead and output.
This functionality would make sense if you were setting and output path, than -fn and -xfn
Also my output is set to D:\Terragen\Output. Same for the general settings you'd think projects would draw off of.
It's just not very linux-y software you'd be paying for and kinda rudimentary bash scripty you get headaches over.
And again, the commands docs show single-use examples. So it looks like -o and -ox are switches, you use either or. As they both are doing essentially the same thing... one just uses a special name. Which is redundant to begin with, but also confusing in docs.
The redundancy in the commands could easily be shortened to something like ./terragen -p /home/was/Terragen/Projects/Background_Galaxy.tgd -exit -r -f 42 -o /home/was/Terragen/out/ -fn Background_Animation.IMAGETYPE.%04d.tif
For the main render, it would simply omit ".IMAGETYPE" from the filename.
Considering extra outputs, in a commercial setting (and even me trying to play with them) should be common-place the node could be smarter, and the docs more condensed.
It could go further and not even need the IMAGETYPE unless someone wants a custom defined naming convention, and add the image type before MIME type.
Yes, I suppose it could. The use of -o and -ox is a legacy holdover from before render elements were supported. There was only alpha. Two filenames were needed in the UI, and each of them was overridden with its own switch.
It hasn't been changed because it would break backward compatibility. But we could replace them both with a new switch with a different name.
Regarding the Linux paths and "not seeing the problem", I'm afraid I don't understand your question.
Quote from: Matt on January 02, 2020, 02:00:27 PMRegarding the Linux paths and "not seeing the problem", I'm afraid I don't understand your question.
That's chalking up to the linux docs and redundancy. The docs give a single-case example using "-o". Than goes on to state
-o <filename>
Set the renderer's output image filename to <filename> before rendering.
...
-ox <filename>
Set the renderer's "extra output images" filename to <filename> before rendering.
...Quote"to <filename>"
It makes it seem like this is a either or switch to use one flag at a time, really. And then no example of usage is given so it's left to the users interpretation.
I'd never assume I'd have to define the whole path and filename twice, for basically the same thing. Lmao I'd assume things be smarter.
And as far as legacy support, that's entirely understandable. But perhaps just release a "legacy" renderer node for those systems. Buuuut being based off peoples managers or even custom scripts; it isn't a end-of-the-world scenario and they should all immediately know what to change in their custom systems.
Maintaining multiple executables for legacy syntax is a bit drastic, but I'll take the syntax change requests into consideration.
Quote from: Matt on January 02, 2020, 03:56:57 PMMaintaining multiple executables for legacy syntax is a bit drastic, but I'll take the syntax change requests into consideration.
Yeah, that's why I noted that the people handling these nodes will know what to change when reviewing change logs, since it's almost certain they manually set up either a manager or script, so probably not even needed [legacy thingy]. People could roll out the changes easily enough.
But I do think the arguments could be better handled. If anything the docs more clear. The impression I got, over re-reading it over a dozen times, it didn't dawn on me that you'd want the full path and name twice as two separate flags. Maybe I'm dumb, or maybe I'm used to other linux docs being more explicit.
It'd also be cool if TG was just installable and had a manual. So query it would be as simple as "man terragen". Especially helpful when remote, saving from opening browsers or carying a copy of the docs, or CDing dirs to get to docs, and back, or multiple screens/sessions, etc. :-X
Maybe a "./terragen docs" command and just tail the docs, for a addition in a pinch.
Since this intended for automated environments and thus likely SSH rather than a console within a desktop.