2013-05-20, 09:13 PM
The switches are in --help. You'll probably see them if you just run it without inputs too (you'll have to look fast if CMD.exe isn't open)
You need scripts to make commandline tools really convenient. And GUIs help a lot too. Its all about keeping everything in separate problem domains. Usually developers are not involved in maintaining scripts and GUIs.
PS: I don't have any plans to work on anything other than x2mdl and like tools for making custom files. I am working on a PalEdit program that can tweak models and save them. But that's a secondary function and it doesn't make models from scratch. I suppose that could be part of the import feature. But the problem domain is not well defined, so I am reticent to interbreed the two. If it did import models it would just call upon x2mdl to do so, and probably with little to no options. Maybe an option to choose an import tool.
I am disappointed that the Assimp project's people are pretty much a lost cause. But I put a lot of work into Assimp, and its a good idea if not a good project. So I'm going to keep using a bastardized version of it for x2mdl. It does more than just import with all of its filters. Cache optimization is really important. If SOM becomes a media darling I might go as far as to encourage programmers to fork the Assimp project to make it a more accessible platform.
PPS: There is a real problem with SOM's x2mdo program. Probably the MPX files too. They are broken into tiny pieces that almost definitely really slow down games. In fact I wouldn't be surprised if this practice is responsible for a lot of the slowness. It's a problem that I intend to look at when I start working with PalEdit again here in a bit. As part of preparing an extension to draw the arm(s) for games...
All that is needed is a Save feature. And I intend for there to be a way to run either PalEdit or Somplayer.dll as a commandline script. It may be a moot point if x2mdl is made to save .mdo files. But opening the models into PalEdit and then saving them should be sufficient to optimize out the many pieces problem. Which should improve performance (ex. a tree model might be 50 pieces when it only needs to be 1, so every piece introduces a restart of the video adapter degrading performance)
You need scripts to make commandline tools really convenient. And GUIs help a lot too. Its all about keeping everything in separate problem domains. Usually developers are not involved in maintaining scripts and GUIs.
PS: I don't have any plans to work on anything other than x2mdl and like tools for making custom files. I am working on a PalEdit program that can tweak models and save them. But that's a secondary function and it doesn't make models from scratch. I suppose that could be part of the import feature. But the problem domain is not well defined, so I am reticent to interbreed the two. If it did import models it would just call upon x2mdl to do so, and probably with little to no options. Maybe an option to choose an import tool.
I am disappointed that the Assimp project's people are pretty much a lost cause. But I put a lot of work into Assimp, and its a good idea if not a good project. So I'm going to keep using a bastardized version of it for x2mdl. It does more than just import with all of its filters. Cache optimization is really important. If SOM becomes a media darling I might go as far as to encourage programmers to fork the Assimp project to make it a more accessible platform.
PPS: There is a real problem with SOM's x2mdo program. Probably the MPX files too. They are broken into tiny pieces that almost definitely really slow down games. In fact I wouldn't be surprised if this practice is responsible for a lot of the slowness. It's a problem that I intend to look at when I start working with PalEdit again here in a bit. As part of preparing an extension to draw the arm(s) for games...
All that is needed is a Save feature. And I intend for there to be a way to run either PalEdit or Somplayer.dll as a commandline script. It may be a moot point if x2mdl is made to save .mdo files. But opening the models into PalEdit and then saving them should be sufficient to optimize out the many pieces problem. Which should improve performance (ex. a tree model might be 50 pieces when it only needs to be 1, so every piece introduces a restart of the video adapter degrading performance)