Well, yeah.So thats it?
Spec:
* Import geometry
* Assign textures
* Render geometry
* Assign pieces a position rotation and name
* Define/calculate groundplate size
* Export s3o
* Animate
* Export spring lua animation script
Anything missing?
1. Needs to use GLSL with more than 2 textures able to be assigned, so that people can preview advanced geometry shaders without having to run Spring. There is no 100% equivalent environment for previewing GLSL that operates like Spring's Lua UnitRendering process that I could find. UpSpring is, unfortunately, tied to a copy of the ARB shaders used by Spring. IMO, this retards people's progress towards using modern shader-based approaches. If you would actually be interested in that, I can give you a fairly detailed set of specifications that I think it should meet.
2. Needs to be able to preview the animation scripts, and give a graph of CPU use.
3. Should have a console where Lua scripts can be dumped, to test sub-sections of an animation script. IOW, if I want to see how a section called "attackOne()" operates, I should just dump the instructions in and watch.
4. Animation scripts have to be very efficient in terms of instructions over time (otherwise, while creating a nub-friendly tool, you will also be giving people a lazy-man's hell- it'll "work", but the results will be useless for practical problems).
5. Needs the copy / paste tools of UpSpring, that allow for efficient workflow with lots of models (for example, you can build certain types of parts and copy them or import them, allowing very fast creation of common things you need, like FX points).
6. Should have an auto-build tool for the new types of collision geometry that Spring can use- spheres, columns, cuboids, that will output the correct parameters as text after letting the user build it with a visual output, so that WYSIWYG.
7. Should have an "icon-building" mode, where you can define a texture to throw on a ground-level quad, can have shadows on, and uses a normal aspect ratio for icons (or a custom one for custom projects).
8. Should be able to handle geometry import from both 3DS and OBJ as whole-model without losing parts. OBJ supports multi-part meshes; there is no real reason why people shouldn't be able to export using OBJ in one go.
9. Should support the Wings model format, for direct workflow from Wings, since it is the de-facto modeler for most people, to increase their productivity.
10. Should handle model transformations, such as but not limited to: cloning with hierarchies, mirroring on any axis, rescaling without screwing up the normal tangents, inversion of facets, and movement of the Piece centroid, preferably with a precision snap. UpSpring can do all of this. One thing that would be especially useful is if cloning across the X axis, automatically rename the Pieces with "$name + _l" or + "_r" so that they're already identified.
11. Should not bother supporting 3DO, other than perhaps basic import of geometry / texture coordinates / surface normals. UpSpring already does a very adequate job of exporting 3DO to S3O, and it's really not necessary to reinvent a wheel that, other than some big experiments I and a couple of other folks ran, hasn't gotten used much.
12. Geometry, when saved, should be cleaned up and use efficient tristripping per Piece.
13. It should support quad formats. IIRC, Spring can render S3Os using quads, but UpSpring forces them to tris. That said, IDK how important that is for shaders, so it should be investigated before anybody thinks about wasting time implementing it.
14. Should allow for manual control of the lights, import of new reflection cube textures (preferably on a sphere, like jK's alteration of Spring works), for testing shaders under different conditions.
15. Should be able to auto-export a complete, lower-case set of Piece names as a text file, for faster workflow when building large sets of models with lots of Pieces (sounds dumb, but every time you have to type out 50 Piece names, it is lengthy drudgery, may cause errors if done improperly, etc.)
16. Should be using a multi-platform set of libraries, etc. (although my understanding is that it's possible to build UpSpring in Linux, I haven't seen a lot of evidence that there have been many people doing so- this limits their participation in Spring).
So, basically, to be a valid replacement for UpSpring... it'd need to do everything that UpSpring already does so well... and a lot more. Frankly, if you're going to actually try and tackle that, by all means, but UpSpring's actually a very powerful toolset if you know what you're doing, it just lacks a few amenities that are mainly about better workflow atm.
I think that instead of reinventing that entire wheel, I'd rather see a simple S3O viewer / shader design lab / animation previewer. Much less hassle imo. Though I wish that somebody felt bored enough to do the piece-name thing. If there's anything I'm sick of, 300+ unit models / scripts later, it's typing in a bazillion piece names into animation scripts. So much else (of that process) either can't be automated, or is copy-pasta work, but that drudgery remains.
I don't personally have a lot of hope about making something that does animation script output. But here are my thoughts, since this is something that at least two people have spent a fair amount of their time tackling:
Ideally, we'd want the output in Lua (assuming that's mature enough yet- and I'm not the guy to ask, I'm still stuck in BOS-land atm due to time constraints). If we're starting a new script from scratch, it would be able to be fed a header file that could feed it additional includes, to speed things up.
Ideally, we'd want a pretty fancy UI, that tracked events per Piece. So you'd click on a Piece, and it'd show a timeline (with logarithmic scaling and the ability to zoom) for that Piece, and any child Pieces. So, for example, a typical human animation, where a lot of Pieces are moving, would show a lot of timelines if you selected the base (assuming that it is being moved, which is pretty common).
But it would also have to be able to have a mode where you could tell it to build a sub-animation for manual import into a script. For example- we generally shouldn't be writing the entire motion of the Unit in one giant loop; some of it's callin dependent stuff. So, for each engine callin, we need a preset in the UI to make that (AimWeaponX, for example), and an "Other" category for all of the things that fall outside the engine's design.
We'd want to build an animation by manually setting a time, building a step, hitting a button to finalize that step and write an efficient animation for those Pieces during that timeframe, then write the next step, and so on.
At the end of constructing a sequence of events, we'd finally hit a button to show the entire sequence in operation.
Once an event is on the timeline, we'd want to be able to step back and forth between event timestamps and add / tweak motion or rotation instructions or new events.
Usually this would need to snap to the nearest gameframe ofc, but giving people the ability to set the snap in milliseconds would be nice, especially for stuff like walk cycles. And finally, we'd want to be able to scale time, allowing us to build our animations in a slow timescale and run it through the motions, making sure it was 100% correct, then hit a button and speed it up. Right now, I frequently have to run Spring and literally slow it down to .3 just to test animations are actually operating correctly, and see where they're going wrong when they're goofy.
We'd want a "make a loop" for animations, just adding a "while X == true --> end" around the animation, but also literally showing us the animation executing the loop. IOW, if I want to do a loop of a guy peddling a bicycle, I want to hit a button marked "loop", and watch him peddle away.
We'd need random-number support, so that animations that call for math.random can be seen operating just like they would when deployed. This is especially important for loops where random stuff could be used to add small variations (this is something that we do in BOS fairly frequently).
Basically, building a visual animation tool for Spring would rock for the artists, and it would instantly make us both more productive and allow us to do things we tend to shy away from now, like building variant animations, detailed death sequences, etc.... but this is a very non-trivial piece of software, and the output and most especially the UI would really have to be right.
