Upspring.

[Gnomre]

Zaphod, a new version is required immediately Screw the explosions, screw linux, screw everything else! It needs done now!

Right now, Upspring has several fatal issues:
1) Its rotations and translations are completely wrong. They're simply not accurate. You have to create three pieces for every single piece you wish to rotate around more than one axis (hey, guess what, not everything is an artillery turret!), and then multiple 2/3 of the values by -1, and even then it's not correct and you have to tweak the hell out of it just to get it the way you want it in game. This is hours and hours of working around problems and tweaking just for one pose for firing the gun, then we have to go back and animate walking and everything else!

It needs to handle rotations and translations EXACTLY the same as the engine. Not one bit of error. There's no excuse, you develop for the engine daily and have the source.

2) Apply transform should not reset the origin. There should be a seperate button for resetting origins. Having to re-rig your entire model just because you needed to rotate one piece is not my definition of fun.

3) The mirroring error needs fixed. In Upspring, my stormtrooper has his officer's shoulder flap thing on his left shoulder. In game it's on his right. It's supposed to be on his right, yes, but that doesn't change the fact that I had to dick around with mirroring to a plainly wrong way in the editor just to make it show up right in game. Combine this with point #1 and it's a clusterfuck nightmarish mess to anyone who wants to touch s3o.

Honestly, we just need to dump BOS and put in a system that doesn't suck. Preferably skeletal animations so we can make infantry with joints that look like something you'd see on a living being, not Japan's latest fucking robot. As great as that'd be, though, we at least need something that ACTUALLY WORKS with the current system. It doesn't need to parse or generate scripts for us, it just needs to report all of the positioning and display the model correctly. Until then, it's pretty much impossible to animate an s3o unit with more movement than turning the gun and barrel to the heading and pitch without spending days for a process which should take minutes.

[BvDorp]

let jcnossen rollout the new map format, he's totally into developing skeletal animations, inversed kinematics etc, so he will be picking up building a new animation system and developing some tool for it, I guess.

LOL, spring is really speeding up

[Argh]

While I'd have to agree with many of your points, Gnome, it's not as bad as all that, and I would like it very much if you'd... erm... not spaz, please.

As my mod shows, we can animate S3Os just fine. Easy? No. Intuitive? Heck no. Possible? Yes. Should it be better? Yes. Is anybody working on this right now? No.

Why? Because it's a lot of very hard, not very sexy work, that is strictly applicable only to Spring development, unlike working on, say, a map rendering algorithm or shaders, which might, oh, I dunno... get JC a job?

As for replacing it with a new format... um... we've been over this ground a million times. To do so, the model code needs to be fully abstracted, which hasn't gotten done yet, and for it to get done, somebody with serious C++ skills and fairly deep knowledge both of Spring and OpenGL/rendering systems is going to have to do it... otherwise, I'd have taken a stab at it already. Really. I'd already be trying it, if I didn't think it was beyond any hope of me succeeding- that area, and the weapon code, are two of the things that drive me nuts about Spring from an engineering side, and I only wish I was smart enough to help

I've read through a lot of the relevant code, and large chunks of it don't make much sense to me... and I suspect that only three people could even think about doing this: SJ, JC, or Yeha, and probably not Yeha. It's not a trivial, little thing, k? We're talking about three weeks or more of coder time, here, from the very same people who are strained to provide what they currently do.

And then, after all that is said and done, then comes the other Big Argument... whose animation suite will Spring use? Blender, which is free and Open Source, but is a terrible modeling/animation environment with a crappy UI, and not always stable? Milkshape3D, which is not free or Open Source, but is cheap, easy-to-use, and has a simple UI, but doesn't support any really advanced features, like time curves, muscles or multi-parent IK? Or something like Max, which is not at all free, isn't Open Source, would force all of us poor modders into piracy, but has a very well-documented file format and very powerful tools? Oh, I can see the flame wars now... and a lot of it would be between the cretins who want Everything to Be Free and people like me, who know the tools, and know that MS3D is worth $25... and that fancy features aren't vital when working with game characters that are usually going to be only 64 pixels high on a user's screen, 90% of the time.

At any rate... please don't yell. It's not constructive, and it's disrespectful. Everybody here is working for free, k? And to paraphrase Churchill, "if you have to have an argument, it costs nothing to be polite"

[mehere101]

Skeletal Animations needs to be an option, but the old style needs a revamp (read: bash with hammer until dead then rewrite them). Both should be available at once, in one peaceful, happy, spring.

edit: Blender is not crappy, its different. I find that most other modelers are hard to use (milkshape is not intuitive enough for me).

[Gnomre]

Strong tools to use the fancy multiplayer water are just as likely to get someone a job. There's a reason there's 18,000,000 upcoming games on unreal engine 3 and all of four games running the Doom 3 engine, and I can tell you it's not about the graphics. It's due to the powerful and documented toolset Epic has created for their engine. Why should Spring be any different? I don't expect Spring to have its own unrealed, but I do expect consistency, especially in a game that's open source and a tool that's made by one of the main developers!

Yes, I certainly know it's possible to get things done with Upspring's current incarnation. And I'm not saying yours look bad or that it's impossible to make any look good. But like you said, possible doesn't equal easy, intuitive, or good. If the program simply displayed accurate values, and handled all possible changes to the model exactly as they happened in game, animating something like a foot soldier or a walker would take 90% less time. The only obstacle left would be timing, and that'd be present no matter what animation system is in place.

And like I said--I know it's less likely that we'll get a new animation format anytime soon. BOS sucks, but it can do the job as long as the tools available help and not hinder the process.

Finally, about the polite thing: Politeness never ever works in this community, you have to come off as firm and sometimes rude to get things done. I had to argue with Yeha for two hours to get the handful of lines of code for the friendly fire tags added. Look at the feature request forum. How many of those have actually been filled? When the devs start actually listening to our requests instead of dicking with multiplayer water, I'll stop being so abrasive.

[Argh]

There's a reason there's 18,000,000 upcoming games on unreal engine 3 and all of four games running the Doom 3 engine, and I can tell you it's not about the graphics. It's due to the powerful and documented toolset Epic has created for their engine.

I'm in 100% agreement with you there... and I've been arguing the case for better content creation tools for months now. If UpSpring merely had the ability to take a given pose and create a "snapshot" of rotational coordinates for each piece, in a textfile format... and had the known problems with orientation / mirroring fixed, it would be a 100% more useful tool, even if we had to take those rotational coordinates and paste them into proper BOS scripting by hand. I know that, and I'm with you on all of this stuff.

Heck, if somebody would just make Servo work halfway decently, that'd be enough- it already has the ability to make keyframes (very buggily) and output BOS scripts (only using NOW, but still, it does work)... and you can export S3O directly to 3DO, import into Servo, and see your model (yup, that works). Only problem is that Servo's keyframe UI is borked, the UI in general is very rough, and if I recall correctly, it reverses some of the output states, so that parts actually rotate bass-ackwards to the way that they should.

The UI stuff may be hard, if not impossible to fix. Fixing the rotational coordinate stuff should be trivial, which I why I am begging Buggi to take a look at it. Ideally though, these things should be in UpSpring, as an "animation room" where you could build and test animations and watch them execute in realtime, using exactly the same code as the game engine. Which would be, short of having an additional tool to allow us to make use of the vertex-moving code in BOS (which, in theory, could be used for complex organic animations) be about perfect. I don't know what it's going to take to get Spring's developers to realise the importance of getting this stuff built, but I'd have to say that it isn't from lack of argument on our parts.

I have a feeling that most Spring devs have never actually tried making complex animations for Spring, and assume that because there are a lot've units made already, that this must not be too bad.

This is not the truth, devs. Seriously. Most units on TAU or UnitUniverse? Oh, they use hacked up OTA code, because very few scriptors have had enough skill to create original animations. Or they're just basic tank scripts. There aren't that many of us who make entirely new animations, and those of us who do... well, it's painful work, most of the time. I cut out many of the things I've wanted to do for NanoBlobs because I just can't spare two-three days on the scripting, not because it would be difficult to make the models or skins.

There are a lot've things that will always be painful- things like using the built-in math functions to return values and have our scripts do certain motions dynamically, for example. But 99% of the problem is just getting the basic static frame-based animations done. And the more complex the series, or the number of moving parts... the harder it becomes. A good "snapshot" tool, or better yet, a true preview tool... would definately fix a lot of these problems, and make building units mainly about getting the art done, which is how it should be, as opposed to getting the art to actually behave in a way that's visually appropriate and attractive, which is the main problem right now.

[zwzsg]

Well, skeletal animation, new scripting language, inverse kinematic, and all, may be very well, but they're much too far off. And to tell the truth, I don't even want them. I'm used to bos and am convinced no one used bos to its full potential already.


All I ask is two simple things, that'll take maybe two minutes to fix up:
- Change order rotation are applied in UpSpring. It must be first Y, then X, then Z.
- Invert the sign of X and Z.

See? Manyfold simpler that creating a new language. Yet it would make scripting oh so much easier. I'm still using 3do, so I don't suffer from right-left inversion. Just texture up-down inversion, but it's not too severe as I don't texture in UpSpring anyway.

What makes us so irritated is that UpSpring could be a wonderful tool, but just because of all those tiny carelessness, it becomes nighmarish to use. Everything that has a sign (axis, direction of face, orientation of 3do texture, the whole model) is inverted half of the time in UpSpring. I don't think adding a couple minus sign in UpSpring would cost tremendous dev time. Yet it would solve us, modders and animation writers, from terrible headache. And the rotation order too. Sign can be changed mentally, it just mindfuck us, but re-ordering rotation, arg, the only workaround I have requires 10min of remaking each 3do model.

[Argh]

Yeah, that would take care of a big chunk of it, at least in the shorter term... also, it would be really nice if it did rotations in 180-degree arcs, +/-, so that we could do TURN commands with the proper sign for speed. Then we'd just have walk cycles that consisted of a dozen or so TURN commands, instead of 60+ NOWs. I dunno which is more efficient on a raw processing level, but I strongly suspect that TURNs are, because the game engine doesn't have to go back to the BOS over and over again...

[zwzsg]

In old TA, rotation speed must always be positive, no matter which way you turn. In old TA, if you used negative rotation speed, then it would turn in the wrong direction: I mean, along the longer arc. I tested in TA and not Spring but I suppose it's the same for Spring, as TA anims looks fine in Spring. But if both what you said and what I said is true, then it probably mean that instead Spring doesn't care about what sign you give to rotation speeds.

But I agree that having angles noted from -180° to 180° instead of 0 to 360° would be nice, it's one of those things, along with multiplying the distances by 2.5 to keep up with the tradition, showing 3do flat colors, and inverting the up and down of 3do textures, that would be nice to have, but isn't as desperatly needed as proper sign and rotation order. So I chose not to list them, so they'd have a shorter list of UpSpring fixes to focus on.

[Warlord Zsinj]

Xon and Dan on IRC are working on a project to convert bos animation to supcom skeletal animation.

How difficult would it be for one of the devs to talk with them, and reverse engineer it so that we can bone animate in some other program, and then use the program to output bos scripting?

[Tim Blokdijk]

I believe some guy on the forum here managed to export 3DsMax animations to Spring..?
He used to post some of his work here in gifs.

[Masse]

I believe some guy on the forum here managed to export 3DsMax animations to Spring..?
He used to post some of his work here in gifs.

dinamik ? found it
http://taspring.clan-sy.com/phpbb/viewt ... highlight=
that gif was awesome looking wolf if im not mistaken

[Gnomre]

IIRC he said he was just copying the rotations down one by one--the same thing we want to do with upspring...

[Dragon45]

IIRC he said he was just copying the rotations down one by one--the same thing we want to do with upspring...

Confirmed. That's how other animators with highdetail unit script have worked as well - copying down the points from 3dsm by hand (or by Excel or whatever), and then using those points as the values int he scripts.

[chlue]

I fear this questions is quity dumb, but I ask it anyway...

What essential is upspring doing?

As far a I understand. You can load your 3d-Modell, assign textures and name the parts of the modell. Then it can be saved in the format spring can read.

Assign textures and naming parts will be done in the 3d-programm anyway, so the only new thing, I see this programm is doing is saving in the right format. If I get this right, there would be no need for upspring in the workingchain if the 3d-programm could export directly, and it would be much easier to get a modell to spring.

Did I get this right, or do I miss something?

(The only 3d-software i barely can handle is Blender, and at least for that, there shoud be an easy way to write an exporter [ for example http://sourceforge.net/project/showfile ... _id=159615 ] )

[AF]

the 3d programs cannot save in s3o however, and the way they save them gets discarded as soon as you open in UpSpring.

Also naming pieces isnt the same in the modelling program as in upspring.

[rattle]

What I'd like is an undo function if you accidentally misplace something and manual editing of the origins. It's a pain to write down several coordinates if you want them "right".

Also replacing a piece shouldn't delete all subpieces and moving stuff around could be easier. In fact, why not leave the origin and x, y, z coords in and only replace the model data? Then again, rasterized movement of model pieces would be nice too, say if you hold ctrl, shift, or alt (or a combination of those) down you'd move them in 0.1, 0.01, 0.001 steps for intance. Like in wings. This would ease up a lot of things.

[unpossible]

quitting on esc is fairly annoying . can't it at least ask confirmation or is it not possible?

[bobthedinosaur]

+1!
need a scipting tool that works with a modeling tool, theres a huge gap inbetween.

[Tim Blokdijk]

And I would like UpSpring ported to Linux