[purCAB]

On 28 April of this year, I posted regarding the entry of the Output Files (Scene Path and Image Path) and Default Paths (Scenes Path and Renders Path). As part of that discussion JD replied that the definition of "path" was intended to be more generic -- meaning that it could be either a directory path or a fully qualified filename. I'd like to revisit and possibly reopen that discussion.

1) The entry of path variables is limited to files and not directories.
When you click on the browse button (...) when entering a "path" for either of the Output Files (Scene Path, Image Path) or for the Default Files (Scenes Path, Renders Path), it is not possible to enter just a directory structure. The workaround is to either hand type the full directory (e.g. C:\Documents\MaxwellTempFiles\etc\etc) or browse to (or enter a specific file) and then hand edit out the specific file name. The good news is that this approach works and allows the entry of a directory, but I think that browse should support the entry of a directory path as well as a file path. Especially so given the generic definition of "path".

2) If one enters a Default Path (via Options Tab in the Scene Manager) and leaves the Output Files blank (via Output tab), then one would assume that the intent is to use the defaults and not have a specific path for this particular render. However, upon execution of the render the Output file paths are filled in with the Default Path data. I do not believe that this is a desirable "feature". It should (unless overridden with a specific path entry) remain blank. In this manner one can reload the Options (via an Options preset) and have everything work. Otherwise, one would need to change the individual output files.

3) Finally, and this is a nit, it would be nice if Maxwell supported the pull-down entry of a specific file type instead of having to explicitly enter the file type as part of the file name entry. For example, when attempting to save an image file, the "Save as type" lists *.bmp, *.tga, *.jpg, etc., but you cannot select one of these, it must be entered as part of the filename. I would think it would be desirable to be able to pick from a list of valid file types.

---
Ken

[JDHill]

Hi Ken,

1)

I think that browse should support the entry of a directory path as well as a file path.

Can you think of any browser dialog you've seen which does this? There are file browsers and there are folder browsers, but I know of nothing in Windows that offers something in-between. It is a bit of a moot point though - even though you can edit out the file name from the Scene Path by hand, you shouldn't want to do that - the render will fail. It (the Maxwell SDK) needs a valid file location to write the MXS file to. Thanks for pointing this out though, I'll fix it so that it won't incorrectly validate a directory path. This is not ever an issue for the Image Path because the extension is explicitly set (i.e. the Image Type parameter) - if you remove the file name that was chosen in the file browser, the extension will be appended to the resulting directory name.

2) I see what you mean. I'll see what it would take to work things around to where it does not actually populate empty outputs with the default values.

3) I can only think of two places where you enter image paths for output; the Image Path in Output Settings, and the Renders Path in Plugin Options. As already mentioned, the Image Path parameter always has its extension determined by the Image Type parameter just below it. As for the Renders Path, I re-worked this heavily in direct response to the other discussion we had about it. From the Renders Path parameter info (i.e. toggle-on the help icon in the Plugin Options toolbar):

• Renders Path
  The path which rendered images will be written to if no path is specified in Output Parameters. This parameter may be set to a specific file name or to a directory. When a file name is specified, it will be used by the plugin to set the image output (i.e. Output Settings > Image Path) path.
  
  If this parameter contains the name of a directory, the output will be sent there, using the current document name as the output file name. It is also possible to specify the name of an environment variable, set between percent-symbols (e.g.: %MAXWELL_ROOT%), which points to a file or directory name, or, in addition to that, it is possible to simply specify a nameless parent directory of the current directory, using a dot/slash format like: '../../'

The Scenes Path in Plugin Options may be used in a similar way. I see now reviewing the updated plugin manual that this additional functionality was not noted. Let me know if this helps you get any closer to where you want to be.

Cheers,

JD

[purCAB]

JD thanks for the quick reply.

1) Regarding the "browser dialog" schizophrenia:
If I step back and take a closer look (pun intended) I would generally categorize path entry under the Option tab (Default Paths -- Scenes Path / Renders Path) as a "folder browser" and path entry under the Output tab (Output files -- ScenePath / ImagePath) as being a "file browser"...but this may not always be the case. The Default Paths (to me anyway) are just that -- they are defaults -- and I think that most of the time people would want to enter a directory path for their default and have the system append an specific file name. On the other hand, it might also be desirable to always put the Scene File into a specific file (e.g. C:\MaxwellTemp\scene.mxs), so this is where there is a bit of a dichotomy. It seems that both views (folder browser and file browser) are valid (at least under the Options tab). If this duality creates a problem, then I would suggest folder entry for the Options and file entry for the Outputs. I guess I would not preclude the editing out of a filename at least for those entries under the Options tab.

2)
Much appreciated.

3) File Type
I was also looking at other parts of Maxwell that use the same paradigm. In MaxwellRender for example, when you save an image you have to specify the file type as part of the file name. Again, this is nit, but I would think that one should also be able to pick the file type from a list on the Save as Type drop-down.

The ability to use environment variables for these types of entries should be quite valuable. I'll test and let you know if I have any problems.

Saludos,

Ken

[purCAB]

JD, I also tested per your comment on having a Scene Path be only a directory. As you suspected this leads to problems, but it turns out that its not that easy (or obvious) to diagnose. Essentially when the Scene Path is invalid and one attempts to export to Studio, nothing happens. There is no error message or warning, etc., but Studio never starts. Attempting to Render directly from SW without going though Studio also fails in the same quite way.

---
Ken

[JDHill]

Hi Ken,

Yes, in fact I only just found this out today by testing your method of manually removing the filename. Apparently, it didn't occur to me to test for this kind of tampering (i.e. basically checking that the specified path has an extension) and it has never come up until now. If you look in the Log Viewer, it should not really be hard to determine the reason why the MXS was not written - that will have to suffice until I add the required validation.

Regarding file vs. dir browsing, I will go ahead and switch the browser in the defaults section to a folder browser, as it is a less destructive default - the SW doc name will be used if a file is not specified, so whichever directory is specified should just end up with alot of MXS/image outputs in it.

Regarding the other parts of Maxwell, where it is indeed necessary to type out '.png', '.bmp', etc. - that is really outside of my range, since it's not plugin related. This is, in fact, the core reason for the plugin having the Image Type parameter and also for the configurability of the extensions which are presented in all plugin image-path browsing dialogs.

Cheers,

JD

[purCAB]

JD, just a quick confirmation that an environment variable utilized for the Default Paths works as advertised. I had to exit out of SW (although unloading and reloading the plugin may have also worked) in order to force the plugin to re-read the environment variables. This is a nice, and very useful touch.

Thanks,

Ken