Keep 3do model support
Moderator: Moderators
Keep 3do model support
Hi please keep support for 3do models in Spring engine. BA recently updated to 105 and all Spring games use them.
Thanks
Thanks
Re: Keep 3do model support
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.
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.
Re: Keep 3do model support
Hello.
I want to keep all 3DO models too, and all Bos/Cob scripts too.
Let compatibility please.
thanks.
Skymyj modder from Tech Annihilation
I want to keep all 3DO models too, and all Bos/Cob scripts too.
Let compatibility please.
thanks.
Skymyj modder from Tech Annihilation
Re: Keep 3do model support
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.
It is good we agree to keep them now before they are mysteriously removed without warning for made up reasons.
Re: Keep 3do model support
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.
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.
Re: Keep 3do model support
3do and cob support ought to have been removed a decade ago.
Re: Keep 3do model support
will it be allowed to play BAR-fork of the engine on springrts.com server?
without limitation?
what about springlobby support?
without limitation?
what about springlobby support?
Re: Keep 3do model support
hmm..isn't the next engine version going to be based off of the BAR fork?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.
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Keep 3do model support
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...
Re: Keep 3do model support
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.
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.
Re: Keep 3do model support
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.
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Keep 3do model support
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...
Re: Keep 3do model support
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.
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.
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Keep 3do model support
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):
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.
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...
Re: Keep 3do model support
"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.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.
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?
Re: Keep 3do model support
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 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...
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Keep 3do model support
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...
Ah - ok. I thought these last few remnants had been replaced in the meantime...
Re: Keep 3do model support
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.raaar wrote: ↑31 Mar 2021, 21:18"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.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.
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?
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.
Re: Keep 3do model support
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)
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)