Spring RTS Engine

Is upspring still in development? If it is, who is managing it? It seems that last commit was by some guy kloot a year ago, and it does not even compile anymore...

No, it's a mess, I'm in the process of writing a replacement but real life is an absolute time sink.

HeadHunter wrote:does not even compile anymore...

because of bad code or missing libraries? because either you can fix.

For reference JelmerCNossen wrote and maintained it, but has since abandoned development.

Kloot and others have intervened and made changes and fixes at various times, but they cannot be considered maintainers. The position of maintainer is open.

Any progress on this project ( or in aiding Das Bruce ) would be most welcome.

Well since it is C++ and just a fucked up build system, I think I can port it to Scons and make it compile and work with more or less modern linux. I will most likely make a ebuild as well. As of actually putting effort into it... I am not sure about it, but anyway, if Kloot has made any progress/has his own repo, I can work on that one instead of the original repo. I dont really care which piece of junk code to patch, just wanna make a new mod for spring.

.

HeadHunter wrote:Well since it is C++ and just a fucked up build system, I think I can port it to Scons and make it compile and work with more or less modern linux.

better use CMake, as its used in spring/springlobby/..., too.

HeadHunter wrote:just wanna make a new mod for spring.

Then make one with OBJ models and forget about 3DO/S3O.

(and wrt. replacing UpSpring, we really do not need yet another poor-man's 3D modelling tool specific to and perpetuating Spring's custom little eco-system of formats that blocks progress for five years)

yes, true, but upspring is still more convenient to use as it has a gui.

Yes, but a GUI that does what exactly?

The assimp importer (current development, next release) allows you to do everything UpSpring does (except convert old 3D0 models) from within your 3D editor of choice using a model format of choice. That makes UpSpring largely redundant unless you insist on staying with S3O/3DO formats.

Most Spring-specific values (height/radius/center/hierarchy) are auto-detected and can also be defined using hidden 3D objects which makes the meta-file entirely optional and only really useful in the case of non-physical geometry like antennas and other non-solid pointy bits that would otherwise make your model difficult to auto-calculate.

You should also be able to do any scaling and normal smoothing in your 3D editor.

UpSpring has had its day. Any effort put into it could be better spent on the assimp importer or some spring gadgets for tweaking metadata.

"You can use any 3d modelling software you like. So long as it's Blender."

Okay, so there is a magic tool assimp, and if it is there, where is a manual for it? How can I use it? At least I'd like to see if it works and get a working model with it. I dont mind using blender, but I can not figure out where can I find a manual.

Is that a joke Flozi?

I'm guessing it was, but just in case it wasn't, or in case you've confused anyone, the situation is you can use any 3D software that exports any common format like OBJ, Collada, 3DS, X, MDL, etc.

Blender is only required if you want to convert existing S3O's.

@HeadHunter: Assimp isn't a tool, it's a library inside Spring that lets Spring handle common formats. The catch is that S3O/3DO (Spring's existing formats) included some data inside the model that UpSpring was an editor for. Since normal model formats don't have this extra data I provided 3 methods for adding/editing it:

1.) Let Spring guess. This should work for 99% of models.
2.) Add some named objects/nodes to your model *
3.) Create a "metadata" file in Lua format with the extra data

Since assimp is currently in the development branch of Spring it hasn't been formally documented on the wiki (this would just confuse people anyway). The best doco is here: http://springrts.com/phpbb/viewtopic.ph ... 65#p463265

That post also has a link to the AssimpTest mod which provides some examples.

Just be aware that the assimp code is in the next release, not the one on the download page. You can download the preview for that release here: http://springrts.com/dl/buildbot/default/develop/ (or build it from source code).

You can always PM me or start a topic, I'm happy to help.

* Specifically it reads properties from scene objects named "SpringHeight" (z-axis is height property) and "SpringRadius" (center is midpos, scale is radius. If scale is 1.0 then radius is x-axis of mesh).

HeadHunter wrote:Okay, so there is a magic tool assimp, and if it is there, where is a manual for it? How can I use it? At least I'd like to see if it works and get a working model with it. I dont mind using blender, but I can not figure out where can I find a manual.

it is not a tool, it's a library in spring that lets it to load different model formats ( like 40 or so ), the current data loaded from models is very limited than what the format allows, since for instance, many formats allow you to save animation infos, textures, etc
atm it's just geometry data, you'll need to also write a small lua file (static data, no programming ) for extra infos that model formats generally don't save

see this thread for more infos: http://springrts.com/phpbb/viewtopic.ph ... 32&start=0

SpliFF wrote:Is that a joke Flozi?

No, but expecting people to hand write meta files is.

As I keep saying the metadata is ENTIRELY optional. You seem to be looking for a problem that doesn't need to be solved.

If you want to do your height, radius in a GUI then use your 3D software to add the SpringHeight, SpringRadius objects and you are done. As an added bonus if you transform your nodes you can transform your height/radius in the same step.

If you want your height/radius piece calculated from your old S3O values then use the Blender import script on your S3O, it will create the SpringHeight/SpringRadius nodes for you.

If you can't be bothered with any of that then just let Spring guess.

If somebody wants to create a metafile editor that would be nice, but it's far from necessary or even important. The metafile is for advanced users with special needs.

Use cases for a metadata file:

• You want to use a model you can't edit (like you ripped it from another game and don't have an editor for it).
• You insist on an export format that doesn't store hierarchy and you want to manually create one (DXF and OBJ would be examples).
• You want to create many models that reuse the same texture without making multiple copies of that texture.
• You want to invert your texture channels.
• You want to do something automated to the model data (the metadata file is a lua script after all, it can do functions).
• You want to hide, rename or reorganise pieces without making those changes to the original model.
• You're an ASCII masochist

These hardly qualify as typical requirements which makes complaining about metadata files pretty pointless.

Finally, even if you need metadata there is no requirement to provide every value. A metadata file can contain one line and still be valid.

I talked to smoth and got the impression that Wings can't be used for setting up hierarchy, origins etc.

Bam, 90% of spring modders can't use their choice of software in the way you intend.

The options become:

1. Use Blender
2. Pirate Max / some other fully featured software
3. Stick with Upspring and s3o
4. Hand write your metafile

not that i have any idea.. but form talks i read around here, i got the impression that having a hierarchy and origin with a 3D model is a quite a basic thing, and if wings can't do it, but you want to new model formats, and still use wings...
i mean... does not sounds like SpliFF fault, really.
sounds like the best solution would be, to contribute to/extend wings.

I'm not suggesting anything is Spliff's fault;

But personally I believe (as do others) assimp (or plain OBJ) are not a panacea for Springs reliance on buggy home grown model builders.

FLOZi wrote: 1. Use Blender

Just to clarify: you *need* to use Blender (to set the piece hierarchy, etc) if and only if you want to run the metadata generator script I wrote. You don't actually have to *model* in it, so long as your $editor_of_choice can export to a format that Blender can import (eg. OBJ). That may make the situation less objectionable to some.

(extending Wings' code just so that it allows *setting* a hierarchy would be decidely more painful than modelling in Blender allegedly is, so making the metadata come from Blender which is fully scriptable seemed like the best option)

Okay, so the simplest way to go now is to throw away wings (which is buggy shit anyways IMHO), and use blender to make just a normal model with couple extra properties and it would work... Well, I'll sure try that and see what happens=)