UpSpring Development

[FLOZi]

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)

Are the obj/assimp metafiles fully compatible yet? Last time I talked to Car he seemed to have some concerns over the obj metafile (and I don't know who else is trying to use obj in a real project, anyone?).

I do accept using Blender only for the final stage, as a direct replacement for Upspring isn't too objectionable, though I imagine Blender won't render the textures in a 'spring like' way regarding channel usage? What you gain in some respects you may lose in others. The likelihood is we'll still be seeing s3os in game archives for some years to come (We still haven't fully outgrown 3do!), and Upspring is still the only tool to really deal with them (yes they can be converted - so can 3do, and yet they aren't).

[smoth]

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

yep

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

Yep

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=)

For you maybe. I have no issues with it. Plus it's texture mapping too I found to be easier to use than blenders. It's all good, by all means make development more difficult for long standing projects, it isn't like I have enough work.

[AF]

For reference here is the metafile ( or the latest example I could find )


modelname.ext.lua or modelname.lua :

Code: Select all

model = {
   radius = 25.0,
   height = 40,
   midpos = {0,-20,0}, -- model center offset
   tex1 = "corraid1_512.dds", -- same as S3O texture 1
   tex2 = "corraid2_512.dds", -- same as S3O texture 2
   invertteamcolor = true, -- invert tex1 alpha channel
   fliptextures = true, -- turn textures upside down
   pieces = {
      root = {
         rotate = {-90,0,0},
         offset = {10,0,0}
      },
      turret = {
         parent = "chassis",
         rotateZ = 30,
         offsetY = 20,
      }
   }
}
return model

Obvious Common sense that appears to be eluding the thread

• Blender is not required to make new models, no involvement in blender is necessary
• If you have an s3o you have a source file, which means you have a modelling tool, which means you can just use that tool and/or a metafile, no blender necessary
• ASSIMP does not replace/remove the s3o pipeline. s3o models still work. There is a lot of resistance that ASSIMP was never needed, that UpSpring worked fine, that people are happy and comfortable with that workflow so why change it? Well nobody changed it.
• You can safely ignore the ASSIMP stuff, and let people who want to use it use it. So why are you complaining and whining about something your not going to use anyway?
• The ASSIMP pipeline provides a new way of doing things that better suits other people.
• s3o won't be made obsolete until pretty much every mod is using the ASSIMP model, which would take years anyway. Heck we still have 3do support, you can use 3do builder if you so please.

Flozi/Smoth, I still fail to see why you are going on about this when you already have workflows and tools that work. Stick to them, they work, they're not changing, you don't have to bother with this new stuff if you don't want to.

All the arguments against ASSIMP claiming ti would ruin the engine, replace s3o, mess with your workflows, are all tosh, as it never happened with the introduction of s3o, and all the old models still work in the ASSIMP builds.

Right now ASSIMP is a parallel way of doing things, much like SM3 vs SMF, and if it doesn't work out it doesn't work out. The refactors to make it possible were done a long time ago, and have already been put to use in the current stable release we've been using for months now.

Let Spliff get on with things, people will test it out further and things will progress, and if they don't, what difference does it make to you? None.

If it turns out to be a total success of epic proportions, yay, but even then you needn't bother with it as your way of working STILL WORKS.


All of this is pointless bickering and scaremongering by people who never believed in the ASSIMP project and haven't got their facts straight and don't want things to change. It hasn't changed though? If it has, file a bug report.

[FLOZi]

AF in *barging into a thread acting high and mighty and totally missing the point* shocker.

I'll make it simple for you:

1. S3O is not disappearing overnight
2. Upspring is not fit for purpose.
3. Several people keep putting ASSIMP forward as the answer to all problems for all people - it isn't; especially for anyone who isn't an existing Blender user.

I am:

1. Pro-ASSIMP. It offers a new range of flexibility regarding formats which can't be a bad thing.
2. In favour of keeping s3o as a parallel format. Which as you helpfully point out it is - but only because of the pressure applied on Spliff to keep it so.
3. Realistic about the long term prospects of s3o vs. ASSIMP + obj formats.
4. Quite willing to discuss the use of Blender as an Upspring replacement (but not an all-in-one solution)
5. Did I mention Upspring is not fit for purpose
6. By the way, Upspring is not fit for purpose
7. In no way meaning to be rude or intransigent, only concerned

I basically agree with (and already stated) 90% of what you posted. However, I prefer to keep my expectations about ASSIMP realistic, and discuss the shortfalls in any expected ASSIMP-based workflows.

Furthermore I think that time invested in fixing Upspring (The original basis of this thread), or replacing it (Bruce's work) is time very well spent indeed, precisely because as you yourself admit, s3o is not going away any time soon, even if it is superseded.

Seen as you insist on insulting myself and Smoth for airing our views, here's my return; No matter what experience you claim to have with game building with Spring, in comparison to others you have much to learn, and perhaps you should consider their opinions a little more deeply.

[AF]

My response is not emotional, its simply stating the facts. Thankyou for stating exactly what your stance is unambiguously, I was not insulting you, rather I was addressing your point of view which was not clear ( and since you've clarified, no longer applies).

As for experience, I don't need to understand the finer details of integral mathematics to know that 1-1 = 2 is a wrong equation, and I've made statements that are within my realm of knowledge.

( and it has been demonstrated that misconceptions and misinformation is present, for which the evidence to the contrary is not in the realms of expert modelling, but in the git repository under rts/Rendering/Models, else I wouldn't have intervened. )

1. S3O is not disappearing overnight I agree
2. Upspring is not fit for purpose. I agree
3. Several people keep putting ASSIMP forward as the answer to all problems for all people - it isn't; especially for anyone who isn't an existing Blender user.I agree but not where blender is concerned save for the specific operation which is unneccesary for new users anyway

My point was that all of this is utterly irrelevant. It's like experts in electric cars arguing about the specifics of steam powered car engines. You don't need to be an expert in either to know that the steam engine discussion is utterly irrelevant to the electric car people.

[smoth]

NONE OF THIS IS A RESPONSE TO YOU AF:

complete agreement with flozi's post.

2. In favour of keeping s3o as a parallel format. Which as you helpfully point out it is - but only because of the pressure applied on Spliff to keep it so.

Very important point. Otherwise s3o will fall by the wayside.

because my other thread is currrently locked. Sorry headhunter but this is important discussion, I didn't want to further derail your thread. Please accept my apology, if it helps you can have this:

>smoth voucher<
you can use it to bug me to help you track down a bug in your mod later


I am not against assimp, I am NOT thrilled about having to become proficient in blender or getting stuck with an unmaintained format. Which is the concern for s3o. We are constantly bouncing from format to format and I just want to get a stable workflow so I can keep pushing out the content I need to make.

if assimp .obj can work out well I welcome the change and will find a way to model in wings and do the rest in blender.. it will be a pain but I will deal with it.

The bigger concern isn't me, I could buy max, I could learn blender. My concern lies with making spring easy to use. While I truly believe that opening spring up to the blender community will yield positive results I still maintain that entry level modeling should be easy and blender is like buy an entire tool set for a screwdriver, it is a bit bewildering.

[HeadHunter]

@smoth: Voucher accepted, nice doing business with you!
@everyone else arguing about best toolchain:
at the moment, as a guy with idea for a mod, i see 2 problems:
1. I can not use upspring because my Wine does not run it, and prebuilt binaries are ancient. So I can try to fix the upspring build, but you are saying it has a replacement, so I have no idea what to do anymore...
2. I just want it easy for the rest of the community, and currently there is a great guide for wings->uvmap->gimp->upspring toolchain, which happens to work with linux at least up to upspring point. But there is no manual/wiki for assimp toolchain, and therefore as a guy who has not done much more than fix some stuff in ZK lua, I can not really work it out myself easily (it does not imply that I can not do it at all).
Therefore,
@everyone
at the moment, I will try to fix the upspring build. Just because assimp chain is undocumented and not ready anyways. If there are no objections, I'll get to work =)

[smoth]

There is currently no replacement for it.

[FLOZi]

Smoth - s3o won't become any more unmaintained than it already is, I'm pretty sure of that, and it won't be removed from the engine for a very long time (if ever) - we won that battle long ago.

There is a question over the future of the s3o toolset - are we stuck with Upspring 1.54 forever, or will someone address its issues or create a replacement? My major concern is when people essentially answer that ASSIMP is effectively a (indirect) replacement for Upspring - a view that works in an ideal world but not in reality.

For the future, new games will hopefully being to transition to ASSIMP formats, most likely using Blender as the final 'rigging' (a barely appropriate term I know but I can't think quite how else to describe the process other than 'building', 'rigging' was always the term used in the S44 dev process) tool - though I do see some drawbacks to this with the current formats (such as the texture viewing issue I mentioned before). This won't even begin to happen until 0.83 is the stable player base.

So all existing games (except those using 3do, and afterall, <canoworms>3doBuilder is a MUCH better tool than Upspring</canoworms> ) and any new games for the next few months at least, will probably use s3o (Some may attempt to use OBJ), because:
1. The toolset, however lamentable, exists.
2. Tutorials and community support (#moddev) is entirely based on s3o

This presents problems of course, because:
1. The toolset is lamentable
2. Doesn't run at all well under wine, cutting off a large contingent of the Spring community

[PicassoCT]

mmh, the way i see it, upspring would slowly evolve to a sort of convert-tool, one that reads as many fileformats as possible, adds whatever spring needs (no need to rewrite blender or max-plugins for every change). Im no fan of direct conversion plugins, they need constant maintance, and as the tastes on 3d-software differ and change over the years, you would need to hop from one 3d software to another to reach a plugin that can read it.

So while i deeply despise some of the bugs in upSpring (most of all the inconsitent GUI) i think it still has some reasons to exist on, as preparation workshop.

Every sort of scaling except for global is not upsprings buisness. (It would be cool if it had some size-reference bult in)

Animation is no longer upSprings buisness (we have springPoser for that)

We are allready halfway there.

PS: Moderators, would multithreating discussions make the forum faster?

[SpliFF]

The issue seems to be simply that wings3d has too few features (it's a mesh editor, not a model builder) and blender has too many features (and quirky interfaces) to make it easy. Milkshape is a better fit but it's shareware (and windows only I think).

UpSpring fills a pretty narrow role. Most of it's features nobody actually uses (like the scripting stuff). It's main role is simply adding the hierarchy, height and radius to a file that doesn't have one. It has no purpose outside the Spring community so developer mindshare is minimal (hence the reason it still has serious issues going on years).

I don't see any harm in using wings3d as your primary mesh editor and UV mapper as long as you understand that regardless of what other tools are in your pipeline you will always have to rebuild your hierarchy every time you edit your mesh. I never saw this as a productive use of time which is what inspired me to add the assimp model loader in the first place.

I think there's a need for a free open-source hierarchy builder but I don't think UpSpring is the right tool. It's too old, has too many Spring-specific aspects and supports too few useful formats. I'll look around though because I suspect there will already be tools for OGRE and other game engines designed to handle this exact issue.

In short, UpSpring and S3O itself were custom measures to deal with limitations of legacy 3d editors and their export formats. However better model formats now exist and so do better editors and tools. Keeping UpSpring around may be prudent in the short term to medium term, particularly for existing projects, but in the longer term it's a poor use of developer time and newer projects should consider the advantages that these newer tools and formats can bring.

@Flozi, Please don't mention OBJ in relation to assimp. It is an even more limited format than S3O. It doesn't support hierarchies (without a metafile) and a range of other things that may become useful later on. OBJ is not a generic term for "everything other than S3O". The recommended formats for use with assimp are 3DS or Collada.

@HeadHunter: If you want to get UpSpring working on linux have a look at the version I already fixed here: http://springrts.com/phpbb/viewtopic.ph ... 61#p442161 . It has a couple of bugs left but it fixes a range of compile issues for linux and 64-bit.

I can also write you up a quick howto for using models with assimp but in the meantime most of what you need is already in the assimp thread and AssimpMod (look in the objects3d directory for examples of models and metadata).

[Kloot]

Are the obj/assimp metafiles fully compatible yet? Last time I talked to Car he seemed to have some concerns over the obj metafile (and I don't know who else is trying to use obj in a real project, anyone?).

Not yet, and only for the former does a generator exist. There is indeed one issue left with it, due to lack of demand.

I do accept using Blender only for the final stage, as a direct replacement for Upspring isn't too objectionable, though I imagine Blender won't render the textures in a 'spring like' way regarding channel usage?

That's true, but then again the "Spring way" is highly non-standard. At some point the texture1/texture2 system will have to make way for more advanced common rendering techniques, otherwise assimp's added support of new formats will ultimately be pointless (beyond removing UpSpring from the equation).

What you gain in some respects you may lose in others. The likelihood is we'll still be seeing s3os in game archives for some years to come (We still haven't fully outgrown 3do!), and Upspring is still the only tool to really deal with them (yes they can be converted - so can 3do, and yet they aren't).

If most existing 3DO/S3O content is still being edited (not created) regularly, it might indeed be worthwhile to patch up UpSpring, but if not, that time would IMO be better spent writing im- and exporters for well-established tools that can perform the same "rigging" functions. (obviously, for Blender those already exist, and IIRC also for 3D Studio)

[smoth]

3ds can go die in a fire, any issues with collada?

[jK]

edited: nvm

[knorke]

That assimp will not remove/break the wings->upspring->s3o chain has been postend numerous times now. Loling around on that is really going in circles.
The only way how assimp "could be bad for s3o" is that in the future nobody might bother to fix Upspring because it might become a less critical tool. But then Upspring is largely unmaintained since long time anyway?

though I imagine Blender won't render the textures in a 'spring like' way regarding channel usage?

Not even Upspring renders transparency correctly...
"spring like" texture channels always seemed a bit hackish anyway. Is there plans to replace that with something better?

at the moment, I will try to fix the upspring build. Just because assimp chain is undocumented and not ready anyways.

The closest there is atm to a assimp manual are some test threads like:
http://springrts.com/phpbb/viewtopic.ph ... del+format , http://springrts.com/phpbb/viewtopic.php?f=9&t=24830 , http://springrts.com/phpbb/viewtopic.ph ... 65#p463265
I do not know if the information in there is enough to start making a game. But you can have a look if you want to use this way in the future since your goal seems to be "make a game" and not "make tools"

[FLOZi]

The issue seems to be simply that wings3d has too few features (it's a mesh editor, not a model builder) and blender has too many features (and quirky interfaces) to make it easy. Milkshape is a better fit but it's shareware (and windows only I think).

UpSpring fills a pretty narrow role. Most of it's features nobody actually uses (like the scripting stuff). It's main role is simply adding the hierarchy, height and radius to a file that doesn't have one. It has no purpose outside the Spring community so developer mindshare is minimal (hence the reason it still has serious issues going on years).

I agree. Also assigning textures, and setting radius is increasingly a thing of the past - unitdef custom colvols and Boxxy gadget.

In short, UpSpring and S3O itself were custom measures to deal with limitations of legacy 3d editors and their export formats. However better model formats now exist and so do better editors and tools. Keeping UpSpring around may be prudent in the short term to medium term, particularly for existing projects, but in the longer term it's a poor use of developer time and newer projects should consider the advantages that these newer tools and formats can bring.

Again, pretty much agree with this, though I think Upspring will be around for longer than you might think.

@Flozi, Please don't mention OBJ in relation to assimp. It is an even more limited format than S3O. It doesn't support hierarchies (without a metafile) and a range of other things that may become useful later on. OBJ is not a generic term for "everything other than S3O". The recommended formats for use with assimp are 3DS or Collada.

Fair enough, but at the end of the day all that is different is one section of the metafile. 3DS is hardly a modern format either.

I can also write you up a quick howto for using models with assimp but in the meantime most of what you need is already in the assimp thread and AssimpMod (look in the objects3d directory for examples of models and metadata).

A quick howto (on the wiki) would be a good start, distilling the important information from various threads and example mods into a full tutorial would be even better.

Are the obj/assimp metafiles fully compatible yet? Last time I talked to Car he seemed to have some concerns over the obj metafile (and I don't know who else is trying to use obj in a real project, anyone?).

Not yet, and only for the former does a generator exist. There is indeed one issue left with it, due to lack of demand.

The lack of an assimp generator, even if the particular format being used holds the origin/ hierarchy data, is something that will need to be addressed before assimp 'take-up' will take off, imo. What's the long term view on the obj loader, now that we have assimp?

I do accept using Blender only for the final stage, as a direct replacement for Upspring isn't too objectionable, though I imagine Blender won't render the textures in a 'spring like' way regarding channel usage?

That's true, but then again the "Spring way" is highly non-standard. At some point the texture1/texture2 system will have to make way for more advanced common rendering techniques, otherwise assimp's added support of new formats will ultimately be pointless (beyond removing UpSpring from the equation).

I understand that, in fact that's kind of what I was driving at, though I guess that will be in the reasonably far future as I imagine it will be the end of s3o if we want a clean implementation? Or is it something that could feasibly be brought in in parallel?

Also textures was just the first issue that popped into my head - are there any others? (for example, Does the obj metafile generator give visual feedback about setting the height and radius as Upspring does?)

What you gain in some respects you may lose in others. The likelihood is we'll still be seeing s3os in game archives for some years to come (We still haven't fully outgrown 3do!), and Upspring is still the only tool to really deal with them (yes they can be converted - so can 3do, and yet they aren't).

If most existing 3DO/S3O content is still being edited (not created) regularly, it might indeed be worthwhile to patch up UpSpring, but if not, that time would IMO be better spent writing im- and exporters for well-established tools that can perform the same "rigging" functions. (obviously, for Blender those already exist, and IIRC also for 3D Studio)

S3O content is still being created regularly (all of knorkes mods, aGorms mod, journeywar; basically all the mods that have started to be built in the past few months are s3o, and probably the devs will stick to the format they've started with) and will be so for a while, editing for much longer (years imo, just look at 3do). I do agree that moving to well established tools is a future goal, but I think even relatively minor improvements to Upspring (auto appending file extensions, fixing the mirrored z axis) would have a lasting effect well worth the time invested. More advanced changes like better handling (and import) of UV maps (this one has caused me major grief lately) and rendering texture2 transparency are a different question - but ultimately it falls to what devs choose to spend their own time on. Personally I am still holding out hope for Bruce's Upspring replacement in the medium term.



Is it me or is this thread turning... civil? Someone better go tell Forb he has to start using Blender so we can get things derailed again.

[PicassoCT]

3ds can go die in a fire, any issues with collada?

Ahem, Sir, Sir, good Sir, you seem to be peeing upon my workflow!

Srsly, i use that for exporting, yes you dont, but im still not convinced im just another smoth-smurf.

Spring Comunity has been tamed. Its getting cold.

[smoth]

The problem with 3ds is that it is a dated and not updated format picasso. It only allows for 1 uvcoord per vertex so any point where there is mirroring etc the mesh is actually split at that point breaking normals. I get tired of repeating it but the stupid forum search will not allow for small word searches like 3ds. so I guess I'll just have to keep repeating myself.

[smoth]

also what is going on with das bruce's work?

[PicassoCT]

so its not upspring who breaks the normals, but 3ds? thats very enlightning, thx.