I'm thinking along these lines:
- =========================================================================
- File Format
What file format(s) would be most appropriate? Let's...just accept that having tried .3ds already, we omit that from the possible formats. It's terrible for interchange, and its structure is not completely documented or easy to parse.
I've looked at the .obj file format, and its structure, aside from parsing its human-readable format, seems to be a perfect fit. I'm assuming this will be good for everybody in some fashion or another.
If there are any other formats, or deep opposition to the .obj format, make a case.
========================================================================= - Conversion Prep
When preparing files for conversion, are there ways people would like them to be organized before the conversion?
Personally, I want whatever it is to allow almost complete automation, without too much mandatory command line fiddling in situations that really don't need it. If you start the program, it finishes, and you have a perfect working set of files (_d.3d, _a.3d, .uc), that's what I would want. The question is what might be the best way to set up our frame files?
At least by default, I'm thinking a folder hierarchy would be the most user friendly. The program sits in the package's main folder. Inside of this folder, there are "m_ModelName" folders (template: "m_*"), and within these are a_AnimSeqName folders (template: "a_*"). In these are your frame models, under some numbering system; Blender, as an example, exports its .obj files in the format "AnimName_nnnnnn.obj" where the "nnnnnn" is a frame number (such as "Firing_000006.obj"). The program would import each model defined with the m_ModelName folders, and each animation sequence for these models with the a_AnimSeqName folders.
This method seems to make sense for the modeling program I use, but I'm curious if this sounds completely weird or won't work for others. For instance, if you are organizing all animation frames as individual objects within one file, and using an internal naming and numbering convention instead of individual frame files, then an alternative would be much more convenient. If you want, please provide some example .obj files to give an idea of how you organize your animations.
========================================================================= - User Interface
Any thoughts on a user interface. A good GUI program, or using a good .ini system for configuration and sticking to the command prompt interface. Model (and surface drawing) preview windows, stats, etc.
The .ini seems like a great compromise for me. For the file staging mentioned in the points above, one could theoretically set up the converter with settings in an .ini to meet their needs, and the converter would accommodate. One could even imagine having specific presets to remove the need for excess fiddling, and have a "CUSTOM" preset for when people want to get technical.
The .ini method is a fairly easy way to do things for both the programmer and the user, where a fully-featured GUI would be a bit more difficult to implement, but prettier and possibly easier for a user standpoint.
Any other comments, concerns, or ideas that are applicable would be great.