Spring RTS Engine

Here is my basic tutorial about how to use UpSpring, from start to finish. This is not a complete documentation of the software's features, many of which, for various reasons, I don't use. But it will get you to the point that your model is ready to animate and will look great in Spring very quickly.

I haven't written a tutorial in forever, because I was under the impression that people were getting how to do most stuff now, but the continuing questions about UpSpring indicate that this is a program most people don't really understand very well, and our documentation about version 1.54 (Euler version) is, well, practically non-existent.

I've written this because I feel like the major modelers around here, who've been here for ages, basically have a "cult of knowledge" on this topic, so it's time to make things clear to newer people, who've probably quit trying to model for this engine in large numbers simply because there aren't good tutorials. Should have done this a year ago, honestly, very little of this has changed since 1.54 was originally released.

This tutorial is designed for all levels of user, including newbies. I think most of the non-newbies will find a few new things in here, though.

Tutorial:

***************************************************
1. Export your model from your modeling application, using the 3DS format, with all pieces named, but no hierarchy.

Do not export without naming your pieces first- if you don't know how to name your pieces, you need to read your modeling application's documentation.

Don't bother with the other formats UpSpring supports. Anybody still using OBJ is wasting lots of their time, and they'll see why, if they follow this tutorial, this is much faster than importing one piece at a time.

***************************************************
2. Click the File menu and select Import. Select the 3DS file, and then import into UpSpring, using option 2. This will bring all pieces into the model, all attached to a "dummy point" named whatever the model's name is.

***************************************************
3. Do any master rotations or full-model scaling now, using the dummy point.

***************************************************
4. Click the Mapping Tab, and load Texture1 (diffuse, teamcolor) and Texture2 (glow, reflect, 1-bit transparency).

If you do not know what Texture2 is all about, please read the documentation about the S3O format in the Wiki first, it will save you much frustration.

***************************************************
5. Save the model, to your Objects3D folder of the game you're working on. Re-open the model, to reset the dummy point's rotations.

Don't skip this step, or you may really mess up your model.

***************************************************
6. Click on the Object menu, and select Recalculate vertex normals.

***************************************************
7. Click the Objects tab. Select your pieces from the menu on the lower right (you can use the CTRL key to select multiple objects- very, very handy), and then adjust them by the amount of smoothing required.

To do this, click the Object menu button, and select Recalculate Vertex Normals, 3DO Style and the sub-menu Selected Objects. A dialog box will come up, and it expects a number (floats are allowed, but not necessary).

To correctly set the welding angles, based on the angles you wish to see welded (and therefore smoothed in Spring), you will need to use greater or lesser numbers.

Higher numbers mean more "aggressive" welding- i.e., a setting of 90 means that 90-degree angles and lower are all welded, and Spring's rounding shader will attempt to show all of those vertices as rounded, in game.

Protip: I never, ever go above 89, because you will start to see welding flaws (dark areas on the rendered model in-game) past that point. There is a real limit to how un-blocky you can make something look. If you need something to be smooth, you must spend the triangles.

Do this entire process with lighting on (click the 3D button, in the upper-left corner of the 3D POV, and it will show you a sub-menu where you can turn on lighting).

You will not see the welding flaws or really see how well your smoothing is working unless you have lighting.

***************************************************
8. Voila, you now have a properly-smoothed model. Now you're ready to make your hierarchy. Make it now, before moving any origins, by using the Cut button to cut pieces you want to make children of other pieces. Select the piece you want to be the parent (higher in the hierarchy- i.e., a person's foot is the child of the shin- the shin is the parent of the foot- get it?) and click the Paste button to build the hierarchy.

If you're me, after this step you'll want to save, then re-open the model again, just to be sure everything is still OK.

***************************************************
9. Once your hierarchy is built, move the origins. I usually just checkmark the "Only move origin" checkmark, which is located below the XYZ Position / Rotation section on the Objects tab, and do it one axis at a time, using the up and down arrow keys- right/left arrow selects the level of precision.

But you can also do it by hand, using the Select Origin Move Tool, which is the red, cross-shaped icon on the icon panel to your left. This is good for quick stuff that doesn't need to be very precise, but I strongly prefer doing it the other way- rigging a model is something you should only have to do once, why not take a few extra minutes and get it right the first time?

***************************************************
10. Save your model, and re-open it, and make sure that all origins are still correct (it's fairly easy to forget to hit the Enter key, to validate a change).

Now you have a properly-assembled, scaled and smoothed model. You're not done yet, but you're getting close.

***************************************************
11. If you need to merge any parts together, use the M key to Merge any parts that you've kept separated up until now. Remember, Merge works hierarchically- i.e., if the ankle is connected to the knee, and the knee is connected to the thigh, and you select the knee and hit the M key, the knee is now gone, and the ankle is now attached to the thigh. So do this part carefully, and remember- UpSpring supports almost unlimited Undo (ctrl-z).

***************************************************
12. Add your point objects, for FX generation, by selecting the piece you want to be the parent from the Objects list, and then clicking the Add Empty button.

***************************************************
13. Scale your hitsphere, if you're using one, on the Model tab. This is called the "radius", and it must be at least 8 units in size to work properly. The next version of Spring allows for cuboids, cylinders, and spheroid hit-detectors as well as spheres, but that goes outside the scope of this tutorial, and you still must set up a radius, it's used for a number of things.

While you're on the Model tab, adjust the model height to be as high as the highest point on the model, and move the center (model center, XYZ, on the Model tab) to the correct location. It is very handy to turn on the option Draw Model Radius + height, which can be found by clicking on any of the viewport buttons, located in the upper-left corner of the viewports.

***************************************************
14. Unless you need it for some reason, you can safely remove the base dummy point now. Use Swap to exchange it with the real root of your model (Spring does not require a "base" piece, in case you didn't know already), then simply use Cut to remove it.

Then, assuming you didn't wreck your hierarchies or anything, it's time to save the model again, re-open it for one last check... and give yourself a big pat on the back- you're done.

You should have a scaled, properly-smoothed, adjusted, origin-set, skinned and completely rigged model at this point.

I know it sounds like a lot of stuff to do, at first, but most of it's trivial, once you know where the buttons are, etc. Note how I use practically nothing else, either- you simply don't need to, unless you're doing something unusual, or working with 3DOs.

Hope this helps the newbies and the non-newbies using a slower workflow. This is my process every time, and I get a model rigged in about 30 minutes, on average.

The time difference between doing single OBJ exports/imports and the 3DS isn't much, as you basically have to prepare the model by cutting the smooting groups from each other, which may take some time, depends on the model and modeling app.

Also, are you sure that the normal length will be fixed when using recalculate normals? Last time I was testing this (scale up by 10) the shaders were using the false normal length resulting in specularity and reflection at a much lower strength and the unit being darker as the unit shader draws the goraud shading too.

The time difference between doing single OBJ exports/imports and the 3DS isn't much, as you basically have to prepare the model by cutting the smooting groups from each other, which may take some time, depends on the model and modeling app.

You're kidding, right? That's dozens of point-and-clicks, with any model that isn't stone-simple. What a waste of time.

And you should never have to cut the smoothing groups apart, unless you're doing something really weird.

How often are you really going to need to break stuff up, realistically? I've had to do this once, the entire time I've been modeling for this engine- for a model with one big surface that I wanted rounded, and some angled areas I wanted hard corners on, that were fairly soft angles.

Anything less than that... no way, tbh. You keep going on about this- show me an example model, any example model, that you can't fix without resorting to separate pieces. I predict I can get it fixed, without taking it outside UpSpring.

I don't do any welding of any kind in UVMapper, I've decided it's just a waste of time, when UpSpring can do it just as well. Most objects look fine at a 45-degree welding angle. Occasionally, I'll have to go up to 61, for objects with 6-sided cylinders, to get them to round, while keeping square edges sharp. Again, you don't want to go above 89- if you have to do that, you didn't model it with a high enough tricount to get the job done- for example, you can't round a square robot leg- if you want it to feel rounded, then you need to add bevels, so that the breaking angle is now under 90 degrees.

Certain things that look OK in Max with a smoothing group are almost certainly not going to actually work in Spring, because Max does stuff differently. I'd almost suggest that setting up smoothing groups is entirely pointless, tbh, because it's never going to come out quite the same, so you might as well see the real, raw geometry.

It's what I do in Rhino, because I know what UpSpring's going to do with it, and Rhino's default welding angle is 10 degrees, IIRC, so unless you alter that, you're seeing raw, flat facets, pretty much.

I strongly prefer seeing the real geometry until I have the model in UpSpring, because then I know where I've built curvature that may be problematical, etc. very easily, by looking at the way the verts are arranged. Maybe I should do a demo with some complex curvature- some of GMN's models have quite a bit, but in general I have stayed away from that, to save polycount. But it might help people understand the modeling process a little better.

Also, are you sure that the normal length will be fixed when using recalculate normals? Last time I was testing this (scale up by 10) the shaders were using the false normal length resulting in specularity and reflection at a much lower strength and the unit being darker as the unit shader draws the goraud shading too.

A. I haven't seen this problem you're describing, and I've scaled lots of stuff up quite a lot. I used to see it, with older versions, but not since 1.54 was released.

I had to use Recalculate Vertex Normals, then save the model and re-open it, to get the buildings for World Builder to shade correctly, but meh, those are really huge, compared to most stuff in Spring. And it worked just fine.


B. If that's a really big problem in your workflow, I'd suggest adjusting the scale in your modeling application, before export, and use the correct scale from here on out. While UpSpring can do these things, it wouldn't surprise me if there were problems once you get past minor scaling. So, don't do it there. Simple.

I'll be the first to say that I model at near-scale for UpSpring, not at whatever scale I feel like, and I use the same scale every time.

I've had to break quite a few models up, not for upspring but to do AO bakes in blender. It kind of works the same as I was applying catmull clark and simple subsurf modifiers to soft and hard shaded stuff for a better result. I usually model in one piece when possible/feasible and often have lots of mixed geometry.

It takes like ~5 minutes for doing single exports/imports. Quite a few clicks indeed, which is why I asked for a mass importing and naming (based on filename) feature.


I always export with a factor of 8 from the model app and never do any scaling in upspring until that bug is fixed.

I've had to break quite a few models up, not for upspring but to do AO bakes in blender. It kind of works the same as I was applying catmull clark and simple subsurf modifiers to soft and hard shaded stuff for a better result. I usually model in one piece when possible/feasible and often have lots of mixed geometry.

If you're doing a bake, your uvmap should already be final, before you hit Blender. You should not be altering the uvmap in any important way in Blender, imo. UpSpring doesn't handle some advanced things you can do with surface normals very well- it's just how it is, and I'd strongly suggest just accepting that, and to not do things that may mess it up, merely to make things look smoother in a bake. Those are the sorts of things you can fix with an airbrush in minutes- don't do it the hard way.

It takes like ~5 minutes for doing single exports/imports. Quite a few clicks indeed, which is why I asked for a mass importing and naming (based on filename) feature.

Well, given that JC's working on something else these days, I really doubt this will happen, unless somebody else chooses to maintain the application. If I knew how to go about that, I'd happily fix it myself- the real problem is that OBJ allows for complete parent-child hierarchies, and multiple, named objects, as part of the file specification, but UpSpring doesn't handle it correctly.

I always export with a factor of 8 from the model app and never do any scaling in upspring until that bug is fixed.

I just try to keep away from giant scaling. I usually have to re-adjust a little bit, but that doesn't cause real problems for me. That said, the biggest stuff I've done (the skyscraper models in World Builder) did cause some problems, but I got them sorted by using Recalculate Vertex Normals, then saving, then immediately re-opening and doing the 3DO Style fix, which corrected it. The biggest issue with big objects, though, is that if they're really huge, you can't preview them very effectively, because the light doesn't work right But meh, that's not something that you're likely to encounter, unless you're building stuff like the Gundam coms, tbh.

not everyone pirates their software

I don't really mind using a .obj export and import for my workflow but I can see how it would be faster to do it in one go. it would be nice if we had a plugin for blender/wings to export s3o. I don't really understand the point of the tutorial though.

UVMapper Classic is freeware. Uvmapper.com, see for yourself.

Nothing else I mentioned needs to use anything but Wings and GIMP. That I prefer other tools is somewhat besides the point, Wings + UVMapper Classic would be a good set of FREE tools to work with uvmaps. And, meh, Pro costs less than a cheap date these days, and you can use it with GIMP just like you do with Photoshop- it just gets sent the Copy buffer.

Uvmapper, ergh...

I am still wondering, why a tut on this though?

Thanks a lot. I've got a couple of models I've been working on, and this'll save me a lot of time. f33d the w1k1.

I am still wondering, why a tut on this though?

Because there hasn't been a complete, step-by-step tut on how to use UpSpring since Maestro's, and his tutorial, beautiful as it was, was very incomplete in a number of very important areas.

I'll add it to the New Spring Site later on.

If you're doing a bake, your uvmap should already be final, before you hit Blender.

It is. I don't apply the modifiers to the UVs of course.

smoth wrote:I am still wondering, why a tut on this though?

I didn't know about points 3, 5 and 6, so I learned something from it at any rate

Huge list.

1. Scale your model to the size you want in your 3d app.
2. Export each piece as obj with normals (pieces that are just mirrored copies of a different piece don't need to be imported).
3. Open upspring
4. Create an empty object, name it whatever you want (I always use base)
5. Select it, then import the objs one by one
6. Doubleclick the empty to expand it and start naming things.
7. Make copies of pieces that need them, for mirrored copies scale them with -1 and then hit apply transform.
8. Use cut and paste to move your objects into a hierarchy.
9. Move the origins (either with the number fields or the origin move tool, make sure to have "move only origin" checked for the former).
10. Add empties where needed.
11. Load your textures.
12. Set the 3d view to display radius and height and then enter those values how you see fit.
13. Flip the UVs in the UV manager if using TGAs, then save to s3o.

Oh wow, we just got a model that obeys our own hard edges instead of needing autogenerated ones! Epic!

Set height slightly higher than the actual unit height, as in when the unit is 8 elmos tall then use a height of 10, because this is where the healthbar goes.

Doesn't have to be much for regular healthbars but I think with people who use the widget you'll need higher units, I'd use 4-8 elmos safety.

I usually use 4, default healthbar is 8 above, IIRC, I'd have to check the Healthbars source to check, but I think it's at least 4-8 higher than that.

This is quite helpful, could it be stickied?

Should be stickied/wikied along with this: http://springrts.com/phpbb/viewtopic.php?f=9&t=18652
Probably as one post about upspring.

KDR_11k wrote:Huge list.

1. Scale your model to the size you want in your 3d app.
2. Export each piece as obj with normals (pieces that are just mirrored copies of a different piece don't need to be imported).
3. Open upspring
4. Create an empty object, name it whatever you want (I always use base)
5. Select it, then import the objs one by one
6. Doubleclick the empty to expand it and start naming things.
7. Make copies of pieces that need them, for mirrored copies scale them with -1 and then hit apply transform.
8. Use cut and paste to move your objects into a hierarchy.
9. Move the origins (either with the number fields or the origin move tool, make sure to have "move only origin" checked for the former).
10. Add empties where needed.
11. Load your textures.
12. Set the 3d view to display radius and height and then enter those values how you see fit.
13. Flip the UVs in the UV manager if using TGAs, then save to s3o.

Oh wow, we just got a model that obeys our own hard edges instead of needing autogenerated ones! Epic!

This is all that needs sticky-ing/wiki-ing.

1. Scale your model to the size you want in your 3d app.
2. Export each piece as obj with normals (pieces that are just mirrored copies of a different piece don't need to be imported).

<Mumbles something about that being the slowest possible way 99% of the time>