Spring RTS Engine

I am currently modelling a unit for a Spring game which consists of many different parts (head, feet, hands, torso) is there a way to import a seperate texture file for each of these pieces of the model

There isnt. But there is a workaround:
You can linearly transform the UV coords of each piece, then merge the texture in photoshop.

Or just map all the parts to one uv map:

smoth wrote: Model

map

hey now, i believe hold the crown for "most autistic use of texture atlases"

but yes, it'll be a matter of combining all of your unit textures into an atlas, and then adjusting and combining your uvw coordinates (it sounds painful but it's really not so bad)

As a non-modeler who gets art from the web, I had to learn this process out of necessity. It consumes 80% of my modding time.

KaiserJ wrote:hey now, i believe hold the crown for "most autistic use of texture atlases"

wasn't trying to claim to that, just showing an example

Thanks for the help guys

This is on my TODO list for ASSIMP models. The importer is perfectly capable of reading multiple textures for models however spring itself does not support storing or rendering them. What needs to happen is textures being handled on a per-piece basis rather than per-model.

That means engine changes including some significant rendering queue changes, because currently spring renders unit display lists in order of the texture names (it does this because it's faster to render all objects using the same texture in one go).

If none of that made sense then the simple explanation is that multiple texture support is possible, but not easy - and someone (me) needs to find the time to do it.

Isn't it just the format limitation in spring?

I used to make models for Halflife back in the day, and even back then it had support for multi-texture maps for a single object.

An example being say.. a gun.
You assigned sub-groups of polygons afaik, just breaking down parts of the model so each seperate object was assigned its own uv map.

Say on a rifle, I would make 1 uvmap for the Reciever, 1 map for the magazine and bullets, and if need be 1 for a scope or other parts, and it worked fine like that.

Then a script file was generated listing each object and its corresponding UV map.

Everything was then compiled into a single .mdl model, and the script kept track of the sub-objects and uv maps.

Its not so different from how spring models are, at least what I remember.

When I made models for spring, there were many different sub-groups all collected together to make a single model, just that it all shared 1 UV map for convenience.

What made it frustrating for me in spring, is that after you had built your model and Uv-mapped it, you'd have to detach each seperate moving part, re-center origins, and a bunch of other annoying stuff.

Having multiple textures for each model, could be a time saver.

Then you could just build your model piece at a time quickly, instead of having to tear it all down again for the final compile.

If its efficient in the end, as far as memory consumption/render ect, I have no clue.

MR.D wrote:Isn't it just the format limitation in spring?

Yes and no.

Per-piece textures are not natively supported because the SJ's did not design the S3O format with that in mind (which cannot now be changed in a backward-compatible way), and consequently the rendering code was not changed to support it either.

However, Spring still is an RTS engine that potentially has to draw thousands of models at once (unlike Half-Life...), and using per-piece textures would be much slower. I thought about throwing in ppt's when writing the OBJ model loader, but decided against it. (Spring could generate per-model atlases, but those might easily grow too large.)

What is efficient for artists is unfortunately not always efficient for an engine.

Really, I'd rather see full-out support for modular units (that is, loading model X for piece Y) rather than PPTs. Obviously it would be a performance hit for large swarms, but for rare units like the ZK commanders it would be a dream.

Following Kloots comments I'm inclined to agree this isn't worth the effort (for reasons other than not having the time). A typical small model may have 5 - 10 pieces so in a game with 1000 units you immediately jump from from 1000 rendering passes to 5k-10k passes. This creates a 5x to 10x rendering hit even for games with single textured models.

Pxtl's idea of using models as pieces is actually doable already using the firetransport capability (a unit can be transported by another unit from an attach point). I've tried this using units as turrets and it actually works surprisingly well - especially if you make the attached unit unselectable.

I suppose this could be streamlined by using a metafile to load a piece from your multi-textured model as a standalone model as well as selecting a texture by name that's linked or embedded in the file. In other words you keep all your pieces and textures together in one model file but let Spring pick it apart to make new models - then use lua to glue them back together as firetransports. The only missing piece in that process right now is the ability to select a texture referenced or embedded in a model and that's not particular hard since Assimp already allows that.