Keep 3do model support

Keep 3do model support

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Keep 3do model support

Post by Ares »

Hi please keep support for 3do models in Spring engine. BA recently updated to 105 and all Spring games use them.

Thanks
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

Is there any talk about removing them from newer engines?

I agree it should be kept though. It's not bothering anyone :)

We'll probably be able to just keep using 105.0 for a long time either way.

Support for 3do could have made it easier for the TA mods using the OTA engine to move. It didn't happen though.
skymyj
Posts: 1
Joined: 23 Nov 2016, 09:40

Re: Keep 3do model support

Post by skymyj »

Hello.

I want to keep all 3DO models too, and all Bos/Cob scripts too.
Let compatibility please.

thanks.

Skymyj modder from Tech Annihilation
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

Yes, all the mod developers I have talked to agree how useful and valuable 3do models are for Spring.

It is good we agree to keep them now before they are mysteriously removed without warning for made up reasons.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Keep 3do model support

Post by Beherith »

To stem the spread of fear an uncertainty: The official spring engine has no plans (to the best of my knowledge) to remove 3DO support.

The BAR fork of the engine, might have 3DO's removed, but this has no effect on official engine builds. I have tools prepared for 3DO->S3O should any game with 3do desire to use BAR engine.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Keep 3do model support

Post by FLOZi »

3do and cob support ought to have been removed a decade ago.
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

Beherith wrote: 29 Mar 2021, 16:09 I have tools prepared for 3DO->S3O should any game with 3do desire to use BAR engine.
Cool, thanks Beherith
saturnV
Posts: 107
Joined: 03 Dec 2020, 07:58

Re: Keep 3do model support

Post by saturnV »

will it be allowed to play BAR-fork of the engine on springrts.com server?
without limitation?
what about springlobby support?
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

Beherith wrote: 29 Mar 2021, 16:09 To stem the spread of fear an uncertainty: The official spring engine has no plans (to the best of my knowledge) to remove 3DO support.

The BAR fork of the engine, might have 3DO's removed, but this has no effect on official engine builds. I have tools prepared for 3DO->S3O should any game with 3do desire to use BAR engine.
hmm..isn't the next engine version going to be based off of the BAR fork?
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

raaar wrote: 30 Mar 2021, 00:33hmm..isn't the next engine version going to be based off of the BAR fork?
From what you can read about the future development e.g. in the "end of maintenance branch" topic it sort of seems that way. While the engine definitely could use some modernization and deprecation of outdated rendering concepts, it seems the BAR fork has both the most progress and active engine developers that have put quite some effort in it so it probably makes sense to just go down that road...

Concerning 3dos I think that's the least of all concerns as even if its support would be deprecated you (even apart from conversion concepts like Beherith has) can easily convert 3dos to s3os with Upspring. It would create individual textures for each unit instead of using a texture atlas approach but it would work so it's not a dead end and the performance gains due to the rendering pipeline upgrades would make the work very worthwhile...
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Keep 3do model support

Post by ivand »

Ok, it started as trolling and I was not going to reply to that, but since we have sane people here, I'll provide some comments.

First: unless BAR fork or myself as a primary contributor included into "main" spring somehow, I don't think it's fair to ask for "BAR engine" being hosted here: there are zero reasons to allow so and to ask for such too. That said the official engine development is dead for 1Y+ by now, so I don't see why not merge into main spring. Anyway it's outside of my control and by now I'm personally happy where I am.

Second: BAR fork is still GPL, so everyone is free to use it same way, the main spring is used. Bear in mind though, I almost don't care about versioning, roadmap, etc. Give or take I support only the latest version in the releases section. We switch engine versions once in two weeks or so, so the pace can be considered high. Due to obvious reasons by now I mostly coordinate with BAR team and fulfill their priorities, however I never do changes that will be beneficial for BAR only.

Thirdly: 3do has special rendering path, that is different compared to every other model type. Switching between paths has some per draw frame cost. Due to converter being available by the time 3do is removed and cost associated with maintaining the old code, I consider it's worth removing it. Actually it's removed in one of the branches along with FFP (no shaders) path, but at the moment there are no compelling reason to enact this version, so we continue to use binaries that has it all.
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

Best is to have it detect automatically, let people pick between s3o or 3do or keep both if you want more developers. Techa converted s3o models to 3do and 3do runs faster.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

Ares wrote: 31 Mar 2021, 02:06 Best is to have it detect automatically, let people pick between s3o or 3do or keep both if you want more developers. Techa converted s3o models to 3do and 3do runs faster.
I think it's not a good idea to stick to a method made for computers from 1997 with 3D rendering meant for the early 2000 era. The impression of 3do running faster is something that comes with a price of being extremely limited in what you can do with your models and textures plus you miss out on the speedups that would be possible on modern hardware (with the aspired OpenGL 4 level already being a bit outdated in terms of what could be possible) which most certainly would make things considerably faster due to faster rendering itself plus probably removing some CPU load / overhead. Or in other words: Don't see the deprecation of 3dos as a downgrade but you just have to convert your models to a different format which renders even faster. So why refusing an upgrade in performance?

In addition to that and repeating what ivand said: Recent engine development has pretty much come to a halt. If we'd neglect the massive work that went into the BAR fork we probably would be stuck with engine version 105 until we come up with more / new engine developers able to invest lots of time. Unfortunately I don't see this happening. The Spring engine is quite an unattractive piece of software when I try to imagine the point of view of new of a newcoming developer. In such a case I'd rather go for a nice engine like Godot with modern Vulkan renderer, support of all 3D, bitmap, video, sound formats I can think of with a nice shader editor. I'd try to implement a RTS logic there which probably also would be different from Spring's synchronous lock step approach. With today's internet bandwidth you can go for a curve based system like Planetary Annihilation used it and not only get rid of most sync-error problems but it also would make programming much easier as you don't have to worry about ensuring identical computation for all systems (hello floating point determinism)...

Or in other words: What's to lose? I see the engine development for BAR as the only extensive work that's going to happen for Spring in the near future and what is / was done makes perfect sense to give a game developer both more advanced graphical options as well as improved performance. So basically you can choose to either maybe indefinitely be stuck at 105 or you can get an improved engine that requires you to do some work to profit from new features and better performance ... while still having version 105 around of course. So as you see nothing is taken from you and in case you for some reason disagree with the changes for the next version - well get your own engine developers and do the changes you see fit. Although I believe they would tell you to do something similar to what BAR does as - well - we now have hardware from decades later than what the Spring engine initially was designed for. We basically are at a stage where our hardware has to emulate the way part of Spring's rendering works as the architectures have changed radically since then...
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

300 fps Techa 3do vs 50fps BAR s3o

Techa converted BAR models to 3do and they run magnitudes faster

3do models are used in every Spring mod, I'm glad all mod developers have agreed to keep them.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

Ares wrote: 31 Mar 2021, 14:13 300 fps Techa 3do vs 50fps BAR s3o

Techa converted BAR models to 3do and they run magnitudes faster
I cannot confirm the performance difference. Tested with the current status of my Maximum Annihilation mod in 105 with the Goliath s3o model vs a respective 3do conversion (i.e. the geometry thrown in as texturing is not possible anyway):
screen00012.jpg
(1010.14 KiB) Not downloaded yet
screen00013.jpg
(998.99 KiB) Not downloaded yet
CPU: AMD Ryzen 3700X
RAM: 32 GB
GPU: AMD Radeon 5700
OS: Win 10 Pro
Resolution 1440p
Map used: Green Fields MK2
Spring Version: 105 (probably with anti-aliasing activated in Spring's settings)

Performance actually is identical - at least when rounding to integer digits for the fps. If your comparison aims at a test you did in BAR itself then yes, BAR runs slower because it applies deferred lighting, normal mapping, on the fly geometry deformation and damage texture overlay depending on unit health and probably even some other things I forgot. Of course that's slower than a standard gouraud shaded and textured mesh. Nobody forces you to use normal mapping or any other GFX shaders on your models though so that's not the point.
Ares wrote: 31 Mar 2021, 14:133do models are used in every Spring mod, I'm glad all mod developers have agreed to keep them.
Simply not true. BAR uses s3o only, Zero-K uses s3o only, Evolution RTS should use s3o only I think, smoth's Gundam uses s3o, Spring 1944 uses s3o. Only games using content made for Total Annihilation use 3do models...
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

ivand wrote: 30 Mar 2021, 21:13 Thirdly: 3do has special rendering path, that is different compared to every other model type. Switching between paths has some per draw frame cost. Due to converter being available by the time 3do is removed and cost associated with maintaining the old code, I consider it's worth removing it. Actually it's removed in one of the branches along with FFP (no shaders) path, but at the moment there are no compelling reason to enact this version, so we continue to use binaries that has it all.
"special rendering path" points towards not getting in the way of the other rendering improvements, it's just "there" and won't benefit from them, which is fair.

I'm not asking for the engine devs to port rendering improvements to 3dos and other legacy stuff if it's troublesome, just that the backwards compatibility isn't broken so it can be merged easily into the official version.

Does that "switching between paths" cost apply if the game and map have no 3do models? How significant is this, really?

Do we have any metrics regarding performance of 3do (and cob) vs the other formats?
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

Master-Athmos wrote: 31 Mar 2021, 19:44 Simply not true. BAR uses s3o only, Zero-K uses s3o only, Evolution RTS should use s3o only I think, smoth's Gundam uses s3o, Spring 1944 uses s3o. Only games using content made for Total Annihilation use 3do models...
MF uses 3do and is "mostly" free of TA content. Zero K uses 3do as well, I think on the Crab and Wyvern, perhaps some of the ships.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

raaar wrote: 31 Mar 2021, 21:18 Do we have any metrics regarding performance of 3do (and cob) vs the other formats?
Lua script vs Cob was tested initially and Cob was by itself a bit faster (to no surprise as it's basically a compiled vs. interpreted comparison). Interactions with external Lua scripts were faster for Lua unit scripts though. I think generally speaking it didn't make much difference while I can't provide any actual performance numbers from the top off my head. Unit scripts in general shouldn't be the computing bottleneck though as pathfinding, LoS, unit physics etc. should be way more demanding...
raaar wrote: 31 Mar 2021, 21:23Zero K uses 3do as well, I think on the Crab and Wyvern, perhaps some of the ships.
Ah - ok. I thought these last few remnants had been replaced in the meantime...
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Keep 3do model support

Post by ivand »

raaar wrote: 31 Mar 2021, 21:18
ivand wrote: 30 Mar 2021, 21:13 Thirdly: 3do has special rendering path, that is different compared to every other model type. Switching between paths has some per draw frame cost. Due to converter being available by the time 3do is removed and cost associated with maintaining the old code, I consider it's worth removing it. Actually it's removed in one of the branches along with FFP (no shaders) path, but at the moment there are no compelling reason to enact this version, so we continue to use binaries that has it all.
"special rendering path" points towards not getting in the way of the other rendering improvements, it's just "there" and won't benefit from them, which is fair.

I'm not asking for the engine devs to port rendering improvements to 3dos and other legacy stuff if it's troublesome, just that the backwards compatibility isn't broken so it can be merged easily into the official version.

Does that "switching between paths" cost apply if the game and map have no 3do models? How significant is this, really?

Do we have any metrics regarding performance of 3do (and cob) vs the other formats?
Well, raaar, if you were not a programmer yourself I'd accept such statement, but you should be well aware, that just "keeping something" doesn't work when you redo the architecture of tightly coupled system. All model renderers follow certain interface and calls semantics and thus if the architecture is reworked towards being more GPU centric, then every model type renderer must be reworked accordingly.

While the cost of switching to 3do might be not very high it has high cost of maintenance and future migration. It's kinda silly to carry 3do to the new age.

Back in the day when I wanted something to be backported into the maintenance from the develop, I was just getting the code, doing the backport and sending PRs.
I do what I do in my spare time for no profit as hobby. If someone is willing to carry 3do, then when I'll be enabling GL4 rendering of s3o and assimp - be my guests and contribute the same (or fallback) for 3do. Making abstract guiding advises doesn't help.

P.S. Unlike 3do, with relatively easy migration path, COB cannot be considered for removal. Too many games use it still and it seems to perform faster than Lua as M-A mentioned. COB removal was never considered. It's something always trolling BA team put into the pot to gaslight everybody.

Seriously though, I'm irritated with persistent attempts to cripple my work and I'm frustrated with administration's inability to deal with trolls (it's not about you raaar). Either you ban idiots and therefore encourage people who do stuff or I don't see any reason for myself to stay.
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

Ares question proved relevant, don't just label them as trolling, you're making the hostility justified.

Consider this my poke in favour of keeping 3do support, Ivand. If you won't, then you won't...just keep doing your thing.

Maybe we'll figure out how to make it compatible later, or make migration easier, or adapt, or just use 105.0.

(I just hope we don't find out in 6 months that 105.0 has some silly bug where some player behavior like a msg crashes the server and be forced to do a quick migration from 3do to use an official dev build with the fix)
Post Reply

Return to “Engine”