Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/crystal/scm/crystal: SubversionException: ("Expected FS format between '1' and '3'; found format '4'", 160043)). Look in the Trac log for more information.

General idea

Encapsulate 'tools' such as: conversion to bindoc, converting textures to DDS, convert renderbuffers to binary format into plugins. Then have a 'toolrunner' application that takes some sort of script. E.g. such a script would bundle common optimization (loading times, memory usage etc.) tasks that would be run on a map to when it is to be released.

A more advanced proposition

The preprocessing management system would be based on different components: some preprocess plugins doing some task, a preprocess manager plugin, and a command line tool.

The iPreProcessManager plugin

This plugin would allow to define a preprocess task to be made by a given plugin. The manager will then be able to execute this task by loading the preprocess plugin, configuring it and managing its execution.

The manager would also implement the iProgressMeter interface in order for the preprocess plugins to report the progress of their task. It may also propose some functionalities about verbosity and log policies.

The PreProcess plugins

The preprocess plugins are simple CS plugins, ie implementing iComponent, and implementing a new iPreProcess interface with eg a single method "bool PreProcess (char* path, char* file)".

In addition to this interface, the preprocess plugins can also optionnaly:

  • implement iPluginConfig if their behavior can be configurable
  • use iVerbosityManager if they can be more or less verbose. (The messages generated have to be sent through the iReporter, not on stdout. Simple notifications are important too.)
  • use iProgressMeter to report the progress of the task

The preprocess plugins should not implement other interfaces than this, unless they can also be used in another context than the preprocess stuff. The iColladaConvertor interface for example should be removed.

The command line tool

It would simply provide an access to the iPreProcessManager by allowing to define and start preprocess tasks through command line options or by providing a configuration script. It would also display the state of the progress meter and the messages reported. Lighter2 is probably a good place to steal code for this.

After that, each utility tools such as collada2cs, 3ds2lev, may2spr, but also the XXXXgen apps, lighter2, docconv, etc could be either removed or moved in a PreProcess plugin. All of them would then be accessible either through the common command line tool, or through any other application communicating with the iPreProcessManager plugin (eg viewmesh).

Ideas of PreProcess plugins

  • 3ds2lev, may2spr, gmesh3ds are probably made obsolete by the Assimp loader, they can be removed or moved in another branch
  • Many applications in apps/import and apps/tools can be moved as preprocess plugins
  • Some tools in cstool can either be moved in a plugin or receive a new plugin wrapping their functionalities
  • lighter2 would be one big preprocess plugin

Notes on progress reporting

The current iLoader and iSaver are lacking a way to report their progress and the ability to be aborted externally (eg when the user click on 'Cancel').

The iProgressMeter can be used by a plugin to report its progress, but the interface is lacking of a way to abort the process externally. A new method eg "bool CanProceed ()" can be added to iProgressMeter so that it can be used by plugins to query regularily if they can proceed on their task.

iProgressMeter may also be extended with a more complex scheme, e.g. with “hierarchical” progress meters (an example is lighter's Statistics::Progress).

Plugins are also lacking a way to pass them the iProgressMeter to be used. Either all the concerned plugins receive a new method eg "void SetProgressMeter (iProgressMeter* meter)", either a new interface is defined, eg iProgressiveProcess, containing the SetProgressMeter method. If a plugin implement this iProgressiveProcess interface then a user application can set it a progress meter to manage the process. Third option: the preprocess plugins look in the registry for a iProgressMeter to be used, but it disallows to have several meters at the same time.

Most current loaders and savers should therefore also use this mechanism (it's not a small task).