TA clash?

[Zoy64]

I hear that there were other factions that were added to TA via third-party. Why cant we bring them back for Spring? I've seen TLL, but it was shortlived. What about the Rhyoss and the Argon?

So, i think those forgotten sides should be brought back in one big mod. Much like the absolute flop "The Showdown," but made entirely of old TA factions that have been ported into spring (along with the originals).

Would it be OK if i took on such a project? I think that the other factions were cool, and that they could hold up to today's Arm and Core.

[lurker]

To actually port them rather than just take units out? That would be really nice to see. If the 2048 texture isn't enough I'll put in effort to allow multiple 3do texture atlases.

[Noruas]

To actually port them rather than just take units out? That would be really nice to see. If the 2048 texture isn't enough I'll put in effort to allow multiple 3do texture atlases.

OH GOD YES

[manolo_]

the units of tll (in xta looks nice) but really hard to balance

[[Krogoth86]]

To actually port them rather than just take units out? That would be really nice to see. If the 2048 texture isn't enough I'll put in effort to allow multiple 3do texture atlases.

I'd rather convert them into s3os before getting a dev on that feature. Upspring gives you the tools to do that...

[lurker]

Convert them to s3o, where they take up much much more space?

[[Krogoth86]]

A couple of 128x128 DDS textures really are Spring's bottleneck...

With too much freetime you even could change the UV-maps of every unit so that you just need one texture file all units can use. I don't know if that saving of filesize would be so good for performance though...

[REVENGE]

I hear that there were other factions that were added to TA via third-party. Why cant we bring them back for Spring? I've seen TLL, but it was shortlived. What about the Rhyoss and the Argon?

So, i think those forgotten sides should be brought back in one big mod. Much like the absolute flop "The Showdown," but made entirely of old TA factions that have been ported into spring (along with the originals).

Would it be OK if i took on such a project? I think that the other factions were cool, and that they could hold up to today's Arm and Core.

Although it's still suspicious, this idea is certainly a lot more interesting than "the showdown". You might even be able to do some intramod sides like XTA Core vs. BA Core, although at that point the balance becomes pretty frivolous.

[AF]

A batch tool that converted units into s3o's using a single shared 2048x2048 texture would be useful.

[lurker]

So put them on a 2048, like spring already does, but make it very difficult to change what small textures are included in the future and make things blurry at piece edges because of mipmapping?

And no, 128 textures are no issue, but a bunch of units with 256 textures will start eating vram like mad.

[AF]

Shouldn't we already have those issues if spring does exactly the same thing automatically?

Such a tool would still be useful as a means of reducing texture memory and aiding texturers who want to share textures between s3o models

[[Krogoth86]]

So put them on a 2048, like spring already does, but make it very difficult to change what small textures are included in the future and make things blurry at piece edges because of mipmapping?

And no, 128 textures are no issue, but a bunch of units with 256 textures will start eating vram like mad.

Well I'd prefer having you work on having the option to disable / control s3o mipmapping and giving upper limits for texture mip-map levels. The latter means that you could do sort of a level-of-detail option with that. You for example include 1024x1024 textures in your mod but depending on the setting the engine only loads them up to the 256x256 level, Making that an engine internal feature or just having to give multiple texture files in the mod the engine chooses from I don't care...

Those features would be way more useful than working on old 3do stuff. The only thing considerable (if it doesn't take too much work) would be to increase the 3do canvas to 4096x4096 sizes. That should be enough space (-> 4x of what we have now) and textures with that size should be supported even by the older cards that can run Spring (at least my GeForce 256 was able to handle that size)...

[lurker]

Pretty sure Intel gets pissy, and I couldn't find much info about larger textures. I'll test what my ATI here can handle. If it's just Intel, we can always downsample the textures.

[Peet]

Nvidia tends to support anything you throw at it, often including nonsquare and NPOT

[KDR_11k]

I think the 2048 limit was enforced by older ATI cards.

[smoth]

I think the 2048 limit was enforced by older ATI cards.

yes

[lurker]

But how older?

[smoth]

doesn't really matter. as it is we have to deal with people who can barely run spring.

I have people tell me that gundam is too demanding for their video cards.

I had people with system crashes back when I had the whitebase with a 2048 texture.

[zwzsg]

Since many authors of these races are long gone, they won't be bitching about you from unauthorised stealing of their works (I'd advise to stay away from Talon though, tro do read Spring's forum).

You might think that by harvesting the dozen TA third party races you'd have an immense wealth of units Spring people never saw with almost no work.

However, what is harder to keep in mind, is that a raw port won't give the expected spectacular results:
- While only one unit has many chance to work in Spring as-is, with hundreds of units you have great odd that some will fail. The BOS/COb script might not run the same in Spring. Or the weapons TDF will be interpreted differently. Or anything else, that will results in buggy behavior. And you will need actual skills, time, knowledge, etc.. to fix that.
- There's the texture issue as exposed above: If you have few units, you can afford to dump their texture into the shared 3do texture space, or to allocate a full texture image fo each unit. But if you have hundreds and hundreds of unit, you need a tool to make a s3o->3do conversion with shared textures image, and this tool doesn't exist. (yes people are already suggesting you all kind of work-arounds, such as forcing every player to buy new hardware for your lame, or degrade already bad texture into blurry mess, but a proper port would be meh enough already that you can't afford to degraded it further with hackish shorcuts)
- Those third party races unit models may have looked okay five years ago in a TA fixed view engine, and even, already in TA you could tell some models were blocky and badly built, but in Spring, any missing under face, any broken walk animation, any small defect will become glaring. And even decent TA units won't magicall become shiny high poly models with just a raw port. If you want it to look a good as newest Spring mod, you have to basically redo everything.

[Argh]

Those third party races unit models may have looked okay five years ago in a TA fixed view engine, and even, already in TA you could tell some models were blocky and badly built, but in Spring, any missing under face, any broken walk animation, any small defect will become glaring. And even decent TA units won't magicall become shiny high poly models with just a raw port. If you want it to look a good as newest Spring mod, you have to basically redo everything.

That was one of the many problems that came up with my abbreviated stab at converting Talon. I got a texture conversion system working, bleach, etc., although I ran into some seriously annoying issues with faces that were just given a shade.

But it used so many hacks to take advantage of OTA's 2 1/2D system, and the models were really blocky, considering it was made so much later, and the results just weren't worth pursuing. It'd be better to just rebuild them from scratch, and do them right, with a full skin. Which, last time I heard anything about it, was TRO's plan.

Lastly... uh... you don't need huge skins for most 3DO-S3O conversions, zwzsg, and so far at least with P.U.R.E., texture memory hasn't been a wall. If you want to talk to me about it sometime for some serious reason, lemme know, I can walk you through the process, it'd be the least I could do for your help over the last three years.

Basically though, it's not a big deal. The only serious issue I ran into was that jcnossen's converter did not quite adjust the texture coordinates of the quads correctly, so they have to be manually resized for a really polished appearance.

Oh... and Treeform finally released his 3DO converter. I haven't had time to look at it yet, I have no idea how many problems it may have but it's there, and it looked like it could be terrifically useful, assuming it can output any common model format at all.

Please take a look at it- if it's just about adding a few underside faces, mirroring and repairing a few things (most 3DOs I've ever sat down with and looked at seriously are modeled really shabbily, with faces that aren't actually matching and all sorts of other crappy modeling issues, but I digress)... then adding them to the uvmap, that's trivial. A lot of work... but basically trivial.

As for script conversions... yeah. I agree with zwzsg 100%. A lot of stuff won't translate, or will, but won't work worth a damn.

That said... meh, the scripting is usually the easiest part, unless it's a really complicated kbot. Do 'em over again.

If people need help, I'll try and dig up some time to write some tutorials about how to do animation for walk-cycles and other common "kbot" types of cyclic stuff, if nobody else will. It's one of those things that's extremely easy once you know how. And it'd be... ah... an improvement over the "tutorials" that Emmanuel put into the Wiki, which are amusing if you haven't read them already