Hi Folks;
This is a list of feature suggestions that I recently accumulated during about 6 full work days using the free edition of Terragen 2.4.
During this time I explored most of TG2's capabilities (except functions). I'll be honest, I am not nor likely to become an expert landscape visualist anytime soon and many aspects of TG2 have me stymied which is a state I expect to remain in for some time to come. But, I am very familiar with software design (I am a software developer by profession) and have used many software applications in my time. So, much of the following suggestions are rooted in what I believe to be good software design and ways that I believe would optimize my own efficiency working with TG2. Hopefully PlanetSide will consider each suggestion below (and any supporting/dissenting comments from others) and be able to implement some of the suggestions in subsequent versions.
I've numbered the suggestions to facilitate references if anyone wants to weigh in on the discussion of specific points, or simply quote the item.
-Pat
1. User option to keep render window(s) on top of other windows. Not modal, just on top of other windows. I'm not referring to the "preview" window here.
2. At time of project close, save all view settings with the project, including worksurface layout. There's no excuse to cause a user to lose his/her worksurface layout.
3. No confirm dialog window when stopping rendering of Quick render. Confirm only Full render stop. Quick render does not have the importance or commitment of a Full render.
4. Don't close render window on New project. Just clear the render window.
5. Don't close the render window on "Revert to Saved". Just clear the render window.
6. Open separate render windows for Full and Quick. As is, only one render window can be open (as far as I can tell). I'm not referring to the "preview" window here. No need to render two at the same time, but don't close/clear Quick render window while Full render because user may want to refer to the Quick Render for whatever reason. Rule of thumb is to never take control of a user interface like this – let user has as many windows open as they want.
7. On help button, don't open the wiki in a new browser window/tab each time. People don't normally need to keep multiple help pages open – they usually just need help on what they are working on at the moment.
8. With Quick render, provide a previous and current render split view so user can see the image before and after setting changes and new Quick render. Could also be multiple render windows that toggle. This is an important request that will improve workflow where user can visually compare the before and after results of setting changes.
9. Bubble help on ALL user interface controls. No excuse for any to be missing.
10. A "close current project" on the File menu. As is, forced to exit the app to close a project.
11. Ability to enable/disable selected node(s) from the node treeview list (upper left).
12. Ability to disable all nodes with one selected node enabled (to "spotlight" a node) from the node list (upper left). Only the nodes of that section (Objects, Terrain, Shaders, etc) would be affected by this "spotlight" feature. This feature would give users the ability to isolate only the node of interest and its role in the entire project. Adobe Photoshop does this in the layers list window.
13. On all windows, show the unit of measure (UOM) for all settings. This is critical to usefulness. Do not assume people know UOM. I can't fathom why UOM would be rarely shown on the user interface of TG2.
14. On applicable settings windows, label the X, Y and Z coordinate entryfields. Don't assume user knows (or should know).
15. When focus is brought to an entryfield, highlight all existing values in that entryfield which allows user to immediately type a new value. As is, user has to be position to the beginning of entryfield string (or swipe all values) to overwrite, which are user movements that are not needed.
16. If #15 above is not adopted, then on focus to an entryfield, place the cursor at the far LEFT when the entryfield is numeric, and to the far RIGHT (as is the case now) when entryfield is alphanumeric.
17. Indicate connected nodes in the setting windows. Just list names of most immediate input/output nodes of the node of the current settings window. Just there as FYI to the user.
18. Be able to enable/disable a node in the network list via right mouse click popup (context) menu.
19. Do not reference TG classic in the wiki documents. Or, have a separate wiki version with TG classic references set my user preferences in the application. Many TG2 users have no need to know what was once done in TG classic.
20. Far too many TBC's in wiki documents. Eliminate all TBC's before writing any new wiki material.
21. Whole sections are missing in the wiki. Fills the holes.
22. Change the color of a node (highlight it) in the network view when user clicks on that node.
23. A "reset node to factory default" button, with confirmation, on each/most node settings windows. This will be critical in situations where a user experiments with node settings, but decides to abandon the node alterations. Using UNDO will likely result in undoing too far back – past the node itself. Discarding the node takes it out of the node network which may impact other nodes. Allow a reset to factory to reset or "clean up" a node to the same state as when first created in the node network (but without disconnecting it in the network).
24. Don't allow the typing on data types an entryfield can't accept/process. For instance, don't allow the typing of characters into numeric entryfields. Allowing this is not only confusing to users, but requires that the code handles bad entries.
25. Provide a "fine tune" adjustment of the setting sliders. Adobe Photoshop does this very nicely.
26. A "node restore point" function on each node settings windows. A "node restore point" would allow the user to experiment with a set of settings of a node and quickly revert back to a "restore point" that was set by the user at some point in his/her workflow for that node. Persist the node restore points with the project. Allow the user to clear a node restore point, with confirmation. Allow the user to overwrite an existing node restore point, with confirmation.
27. Ability to name incremental saves by appending string that user provides at time of the incremental save, not just 01, 02, etc.
28. At least one user definable "custom" render profile where user can set own render settings without losing Full and Quick render settings. Useful for an "ultra fast test render" per user's workflow, or whatever. Persist this custom render setting with the project.
29. Ability to save/export just the camera position so that user is not forced to do an incremental save for each scene camera view. Allows users to produce multiple/many images from the same project without doing an incremental save each time. Same result could be achieved using multiple cameras in one project, but the "camera position export" feature would still be useful.
30. Free version: DO NOT CHANGE RENDER SETTINGS when they exceed the free version limits. Advise the user and stop the render, but do not ever change anything programmatically.
31. Don't overwrite an existing file on incremental save.
32. Incremental save does not handle dates/numbers in filename properly. For instance file name of "MyTGTest-08102012" incrementally saves as "MyTGTest-08102013". In all cases, incremental save MUST append to the file name, not alter the existing file name. In this example, much better to have incrementally saved as "MyTGTest-08102012_01".
33. Highlight the node currently in view in the Network window, don't just center the node from the settings window "Centre node in network" function. Might also want to zoom in the network window when this function selected.
34. Trap errors!!! When TG2 crashes, I see no evidence of a error log or option to send error dump data back to PlanetSide. Usually when an app crashes, it's because an error occurred that was not "handled" within the application and, as such, the developers will never know why the crash occurred, let alone that a crash did occur. PlanetSide developers MUST make provisions to capture fault information if it is obtain maximum stability. If fault information can't be captured, then the application must capture the state of the application at the time of the crash for review and analysis. Nothing will cause software to be abandoned faster than instability and unreliability. While a hobbyist might survive a crash a day, serious VFX production houses are likely to throw a fit when they lose valuable work via a crash. Another strategy that should be adapted is to do a fast project save on a crash – a good way to save customer goodwill. Unhandled errors (crashes) must not be tolerated or must be made as non-destructive as possible.
35. If the free version is intended as a "buy me" trial only, then ignore this suggestion. If, on the other hand, PlanetSide actually wants people to get good results in a noncommercial (hobbyist) manner, then this suggestion will go a long way to creating loyal users, and is more likely to lead to license purchases IMO. In the free version, increase the maximum allowed resolution to 1800x1200. At that resolution, a user would be able to obtain a 6x4 inch print at 300DPI (300DPI is magazine quality and well within even inexpensive home ink jet printers). At the current limit of 800x600, a 6x4 inch print can only print at 133 DPI (dots per inch) which doesn't do much to show TG2's capabilities from a print, let alone a user's abilities. I am personally reluctant to show anyone my TG2 work printed to 6x4. Of course, 800x600 is not an issue if a user will only ever show TG2 images on a display device at 72 PPI (pixels per inch). But I would assume that many will want to print their TG2 work for personal archival or for showing family/friends when a computer is not present. In short, a 6x4 inch print with the current free version limits is poor testament to TG2, as well as authors. In fact, just forbidding commercial use and no render station keys is plenty to limit the free version, so I don't see the logic is very low resolution limits (such as 800x600) except to cause enough pain to drive people to buy a license key, which is not an effective sales strategy for the hobbyist. But like I said, if the free version is trial only, then keep the limits and change your website's "Buy Terragen 2" page to read "trial" rather than "non-commercial".
