UpSpring Replacement Wishlist

UpSpring Replacement Wishlist

Share and discuss visual creations and creation practices like texturing, modelling and musing on the meaning of life.

Moderators: MR.D, Moderators

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

UpSpring Replacement Wishlist

Post by Argh »

Moved here, after realizing that answering AF's query had turned into a derail. Sorry, this is long.
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?
Well, yeah.

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.
User avatar
Pressure Line
Posts: 2283
Joined: 21 May 2007, 02:09

Re: UpSpring Replacement Wishlist

Post by Pressure Line »

There was a util called 'Lazyscripter' for 3do models. You could load a 3do model and it would generate a barebones script (that would allow you to load the model into TA/Spring,even though it wouldnt do a lot), with a full list of piece names.

Something like this for s3o would be nice.
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: UpSpring Replacement Wishlist

Post by Guessmyname »

I agree with everything except 12. Have that as an option / tool you can use, not something done at every save. Optimisation is the modeller's responsibility; I personally would get irritated very quickly if the model exporter was fiddling my meshes without me knowing or being able to control it.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

By "optimization", I do not mean tricount reduction, GMN, just efficient storage of the resulting display list.

IOW, it would not fiddle with your work, it'd just store it so that when rendered it was as efficient as possible. IIRC, UpSpring already does this. Don't worry, basically. This is just about how it's stored internally.
Satirik
Lobby Developer
Posts: 1688
Joined: 16 Mar 2007, 18:27

Re: UpSpring Replacement Wishlist

Post by Satirik »

can't upspring be improved ? why do you want a new software ?
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6238
Joined: 29 Apr 2005, 01:14

Re: UpSpring Replacement Wishlist

Post by FLOZi »

Never tried to use it yourself then
User avatar
MidKnight
Posts: 2650
Joined: 10 Sep 2008, 03:11

Re: UpSpring Replacement Wishlist

Post by MidKnight »

How much more effort does implementing MD5 take? If we could get md5 support, we'd be able to totally forgo upspring and get cool mesh deformation/skeletal animation. :wink:

EDIT: it doesn't necessarily even have to be md5. COLLADA or even 3ds would probably work
User avatar
Tribulex
A.N.T.S. Developer
Posts: 1894
Joined: 26 Sep 2009, 21:26

Re: UpSpring Replacement Wishlist

Post by Tribulex »

zpock, where are you. why have you forsaken us.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: UpSpring Replacement Wishlist

Post by Kloot »

MidKnight wrote: How much more effort does implementing MD5 take?
A lot. You could read some of the older topics about it first.

(TLDR: MD5 meshes and animations are easy enough, but animation control is very hard to combine with Spring's scripting setup; think about how they would interact with weapon emit points fex.)
krychle
Posts: 46
Joined: 01 Jul 2006, 00:09

Re: UpSpring Replacement Wishlist

Post by krychle »

Hi there i'm happy that someone opened this "issue" about UpSpring. It is pretty long list of requirements from Argh. It's good to see everything in one place, i didn't realize how much things are needed for full feature unit editor.

Anyway, I still think that best solution will be to use Bleneder as base for the editor. I don't want to look like Blender fanatic, who says that this is only solution. I've just count needed work (resources) for making such editor. Main fact is that main time consuming tasks in making models are modeling, texturing and animating (i think). And my personal opinion is that Blender is best for this tasks (it's GPL, multiplatform, well supported, ...). You just need export data from Blender to right file format.

The next issues about testing the models can be soved by making some Blender <> Spring unit testing "mode" (I didn't find right word). You should be able create script with some button like "Test in Spring", which will export all data from blender to some folder and run spring in some special testing mode to test the model animations, GLSL effects, .... Than Spring should be able test anything and make any report for you.

And about Lua; Blender is using Python for scripting and Spring is using Lua. There are exists Lua to Python and Python to Lua bindings. So I think there should be possible to execute Lua unit animations scripts inside Blender for example.

Ps.: I don't have much knowledge about Spring code (handling of animations, 3D objets, efects, ...). But from what I know about it and about Blender I can say that you will need to do at least same amount of work to make unit dedicated editor or to make editor from Blender. If you will need some closer informations about how "something" can be made with Blender, just ask. I will try to find some examples from other projects which works with Blender.

... last thing, please keep in mind that i don't have a good english (it's hard to expres myself) so take words like will, should, maybe, ... restrained. I don't want to order anything to anyone ...
User avatar
AF
AI Developer
Posts: 20686
Joined: 14 Sep 2004, 11:32

Re: UpSpring Replacement Wishlist

Post by AF »

Now arrange requests and specifications into milestones
User avatar
AF
AI Developer
Posts: 20686
Joined: 14 Sep 2004, 11:32

Re: UpSpring Replacement Wishlist

Post by AF »

In the meantime, here's a concept sketch from Icarus I never got round to putting up

Image
Attachments
icarusUpspring.png
(540.42 KiB) Downloaded 3 times
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: UpSpring Replacement Wishlist

Post by smoth »

is someone going to do this or is this another "idea guy" thread. :evil:
User avatar
AF
AI Developer
Posts: 20686
Joined: 14 Sep 2004, 11:32

Re: UpSpring Replacement Wishlist

Post by AF »

The Icarus Unit Exporter was not subject to the forums golden rule, as such peet never exposed it, and it was never canceled. ;]

Though I have yet to start on it, the components necessary are WIP, and when finished can easily be put together for a basic version of the above. From then on I would follow my planned development model of maintining a minimal core and providing the means for the community to extend and distribute.

Thus I would expect the community to implement extra model formats and tools/utilities.

In the above at the top you have a time line, to the left are discrete animations, composed of smaller animations and primitives, I expect that at the very end the user would then write the lua code to call these animations, but the actual piece turns and rotations would be generated by the tool.

Along the right woud be the classic hierarchy of geometry and points, represented by a piece name and an overview of the model at say 30% transparency all white, with the piece in question highlight/normally drawn.

Along the bottom being a toolbar with panels for options or tasks ( though Id expect they could be dragged down to the main strip to save time
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

@Smoth: IDK, but it can't hurt to talk about this, there hasn't been serious discussion of this in a long time.


1. On MD5: treat MD5 meshes and animation calls as entirely separate objects that don't interact with BOS other than a callin to BOS saying that they have reached an endpoint. Make BOS responsible for timing and new instructions, or interrupts.

Don't worry about weapon points, etc., you're absolutely right, that can't be dealt with in MD5 easily. But matching them with a MD5 state in space would be pretty trivial, so long as we're not trying to make them actually dynamic.

IOW, I call an animation for "shooting gun to the left while running" for a humanoid character... in BOS, the workflow should be a Lua callout to the MD5 rendering state, calling a canned animation, and the fire-point should be moved to the right position (it is one of several points in an ordinary S3O). Smoke and mirrors, man. It won't be that bad... IF we have a preview environment where we can see MD5 stuff while we are editing a S3O (to write down the numbers). Canned animations are going to be Just Fine, I swear it.

The only major issue, and this is a biggie, is that MD5 mesh origins' positions / rotations need to be accessible via COB. This would allow us to "attach" items to MD5 that are actually S3O, like, say, a turret model on top of the armored howdah of our Death Diplodocus.



2. I can see both sides of the Blender argument. On the one hand, I hate Blender, the more I learn about it, the less I like it, and want as little to do with it as possible. But that's my bias, and it's largely because I just don't like the Blender UI, and probably never will.

On the other hand, it is the only Open Source solution available atm that meets most of the initial requirements (can load various model formats, supports animation, MD5 exporter is already a reality, has all that powerful Python support, etc.) and while I have some trouble imagining the UI that I think we actually need being built there, it may be practical. That said, the proposal is for a toolset that would be used at the end of the workflow- iow, the artist has already gone to the considerable time / trouble to build the model in the environment of their choice, now it's time to make it operational and useful as a game object.

As for the "testing mode", that's why being able to run the scripts and operate GLSL shaders is a requirement. UpSpring can sorta-kinda-theoretically be used for animation playback, but the reality is that that stuff was half-finished before JC ran out of steam.

Running Spring, even in "test mode", is like swatting a fly with an atomic bomb. We want to avoid that if we can, we want everything including the rendering pipeline to operate 100% like Spring does (this is another area where I can't imagine Blender's GLSL support, which is robust, behaving like Spring's rendering path, but I just don't know) and, more importantly, it takes considerable time, which really adds up when you have to do it a dozen times or more per model. That it's the only choice atm does not mean it's good.


3. I will think about UI stuff. I like the idea of a simple 1,2,3 workflow with "rooms" and tabbed approach to workflow.
User avatar
SinbadEV
Posts: 6475
Joined: 02 May 2005, 03:56

Re: UpSpring Replacement Wishlist

Post by SinbadEV »

I don't know if it's been mentioned, but ideally you could get a model into full spring compatibility with the proposed tool... aka snap or import a buildpic, generate the needed scripts and associate a corpse... perhaps an intermediary export format xml or LUA or TA style or something that is human readable but also could someday be used by a feature rich game module editor.... I would suggest just going full hog on LUA for unit defs etc... if it was the easier way to do things it's more likely people will adopt it.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

I guess it wouldn't hurt to have it output a bare-minimum Lua template of the unitDef, but I am pretty dubious about one-stop-shopping concepts- that would turn into a complete monster of a project pretty fast. I would not want to see much valuable programmer time spent on yet-another glorified text editor, basically.
User avatar
AF
AI Developer
Posts: 20686
Joined: 14 Sep 2004, 11:32

Re: UpSpring Replacement Wishlist

Post by AF »

Which is why you write up an extensive extension setup, if there is demand for something, it will be implemented and the extension will become popular!

The idea I had above was more that you would be able to open up a unit from a mod and look at it, that then turned into a minor rival of upspring.

Eitherway whoever does build this tool, a scripting API is a must have.
User avatar
MidKnight
Posts: 2650
Joined: 10 Sep 2008, 03:11

Re: UpSpring Replacement Wishlist

Post by MidKnight »

AF wrote:In the meantime, here's a concept sketch from Icarus I never got round to putting up

Image
Icarus ended up getting hired by Google, didn't he?
User avatar
thesleepless
Posts: 417
Joined: 24 Oct 2007, 04:49

Re: UpSpring Replacement Wishlist

Post by thesleepless »

once blender 2.5 is out i'm going to do more work on the S3O script for it.

but currently it works and you can download it and use it.

blender imports geometry from many formats
can assign textures
render geom
assign position rotation and name to pieces
doesn't auto calculate groundplate size but you can set it with an object
exports s3o
animates
exports cob (but it's pretty limited so far, once 2.5 is out i'll make it export lua animation scripts)
supports GLSL stuff
doesn't import 3do yet, but easy to add if i could be bothered.
fully cross platform
Post Reply

Return to “Art & Modelling”

cron