Interface Issue – Filter Forge

Rendering, viewing and managing filter output:

It might be easier to preview, render and mange filters with the following suggestions.

1. Filters need to be able to have a place to live. Without basic organization any passionate Filter Forge (FF) user will generate a huge line of icons in no time flat. Two levels of folder structure should be plenty. It would be outstanding to be able to have a ‘in progress’ folder and a ’starship hull’ folder, etc.
2. Rendering should be handled in a dedicated interface. The existing filter draw area for the main interface would be augmented and changed slightly. All filters would be subsampled to a smaller and standard size. This would allow quick browsing with more then the itty icon for a judge, and also allow exploring the presets of each filter quickly. I know it’s currently like that, but only if an image exceeds a certain size. I’m suggesting that there be preview window of about 400×400. This would become a very useful tool to avoid rendering with small mistakes undetectable during preview. The additional interface elements would be ‘render size’ with appropriate file options.A standard magnifying icon would allow users to zoom in to print resolution IN the preview window which would take considerably less time to tweak and test for final large renders. Included would be the traditional ’spacebar handgrab’ ability to move the texture to different areas while zoomed to 100%. Additional preset zoom values could be availabe, perhaps 10,25,50,100, and 200% could be made into a popup menu. If live handgrab would be problematic arrow keys could be mapped to a grid system where the render zone could be broken into preset pixel ranges. For example, while rendering a 5000×5000 pixel image I may have interest in seeing only two spots in the final render. A simple reticule could be applied to the borders of the preview image bezel and simple shading could be used like a spreadsheet hilight to indicate which grid from the original is being currently displayed. The arrow keys would move the ‘zoomed view window’ up or down right or left.
3. Hard rendering should be left to the ‘render button’. Filter Forge is constantly sucking CPU power rendering. Only a small percentage of that is required by me. I often don’t need to render anything except previews. I also love to work on my laptop which has a 1920×1200 pixel display, which is perfect. The only problem that it’s a desktop replacement ‘type’ of notebook so the desktop P4 is constantly getting really hot, and the fan is annoying. This only occurs when I’m working in Filter Forge. Even Lightwave doesn’t bring my laptop to this state of heat exhaustion. This render window idea helps. There is no reason why there can’t be display render levels in Filter Forge as software like Lightwave or Hexagon. Most of the time I only need a general idea of what my changes are doing to the output. If we could choose a more simplified output and speed up responsiveness and leave the heavy render to when we are walking away to get coffee… that would be a good thing. There should be a way to do any possible thing on output with a simple interface. By adding a ‘render full image’ checkbox you gain the ability to render a zoomed view at any resolution! The one constant I have found as a builder of filters that the end result is usually much different. That goes without saying that the render preview would be the aspect of the chosen dimensions, which could be input manually or selected from a dropdown list (storage of custom setups possible here).
4. Move channels and AA settings to the render preview interface. A simple panel of dropdowns could centralize this process. Better would be a list of buttons; by clicking on a button you would set the output in the render preview to that channel, by clicking the checkbox beside it you would tie that output to render list, in effect, what we see now, and the stuff that will render when I click ‘render. I can’t imagine why one would want your filter presets to be the holders of that information. When I want bitmaps it’s always for the same reason, to show people, finish a job, etc. Since the preview panel is omnipresent viewing and changing filter parameters it would be more useful to remember settings per filter preset in the preview interface. It would be useful at this point to be able to apply previously adjusted and custom settings to new filter presets. For example, I always output large filters for print at the same resolution, so I would create a ‘filter for print’. By selecting more then one preview preset for any single filter preset will add the additional sizes to the render list.
5. A batch render list. Context sensitive menu addition ‘add to render list’. I was thinking that the render list could live under the preview interface. Since from left to right the preview window and the settings cluster will leave a vacancy right below, which could be an interactive , persistent batch list of things to render. In list format basic info would be immediately apparent. Clicking on a list item would select that item. If render would be clicked now, the list would render from this new point until finished, then the renderer would start at the old number one and finish the list. A selected item would take over the preview panel. A new button would appear (if context) “show filter” which would change from the previous filter to the one generating the preview. Items in the list can be moved up or down or better would be drag and drop. A fringe benefit would be to save the list. Running the list file (like a retrospect ‘run’ document) would boot the render core and render with a dialog box progress bar. This would allow someone to sit down at the workstation, run the render shortcut and Filter Forge would automatically render out anything waiting in the list. For that matter it could be treated like a system idle program. That would be really useful to do some filter work. Add them at high rez to the render list (alt-shift-R) When I quit filter forge and left my workstation the small task sees the run document is new and executes it while the system is idle. The next day I sit down and a bunch of beautiful high resolution textures are sitting in the FF render folder. What… It could happen.