Keep 3do model support - Page 2

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

ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Keep 3do model support

Post by ivand »

No problem, I'll keep doing my thing be assured.
Good luck staying on the prehistoric age technologies forever.

P.S. Requesting permabanning of this account.
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

Master-Athmos wrote: improved engine .. "s3o" better performance
Master-Athmos wrote: tested .. "3do" performance actually is identical
the perfomance gains are a myth, 3do removal is a major change that warrants consideration of others
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

regarding the 3do -> s3o conversion, I've made a test a few hours ago: converting a 3do to s3o using upspring and testing it ingame.

Upspring has an option to generate a texture atlas .bmp image, but it'll contain only the textures used on the unit, not all textures on the texture directory, so different units will have different atlases (inconvenient).

The unit showed up textured on upsring, but when i saw it ingame, it showed a flat blue texture and the model was rotated backwards. I also remember some issues editing models using upspring vs using the 3do builder, i think the flat colored faces were somehow incompatible.

A relevant question is also : is s3o the best format to use? doesn't spring also support other more "mainstream" formats?
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

raaar wrote: 01 Apr 2021, 02:34A relevant question is also : is s3o the best format to use? doesn't spring also support other more "mainstream" formats?
You probably could make the import of other formats work via Assimp but in terms of the actual renderer this won't make a difference. I mean the basics are very simple - you render a UV mapped mesh and that's it. Ok - sounds easy but can get complicated in its implementation and that's where part of the OpenGL4 upgrade is supposed to come in (although I guess it's for the most part about the shader integration)...

Apart from that doing an atlas texture with s3os is possible while you of course can ask the question if you want to do that in the first place. Of course - when coming from 3do models it makes sense to keep the atlas texture concept and the prospect of a tool that automatically converts all 3do textures into an atlas and sets the UV information accordingly was made so you don't have to do it by hand which totally is possible although surely being busy work you'd rather have an automated converter do. Unique textures for every unit has it's advantages too though as you are more flexibel, can add more details and make them have a "less generic" look with repeating patterns everywhere...
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

Master-Athmos wrote:sounds easy .. totally is possible
You showed untextured s3o is equal perfomance to textured 3do, no mod is using untextured models, not a fair test.

Show textured s3o vs textured 3do perfomance, you said its very easy to do and won't be any hassle for mods, show us.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

Well first of all I said it's easy to convert 3do into s3o. In the given case I converted the goliath's s3o model to a 3do (as it has rather a lot of polygons so a performance advantage shows even better than for using a very low poly 3do). So the s3os aren't untextured in my previous reply but the 3dos had no texture. I already regretted having chosen the goliath as you now made me apply textures to over 1000 faces in 3dobuilder - so I hope you'll appreciate that...

So here are your results:
screen00014.jpg
(910.13 KiB) Not downloaded yet
screen00016.jpg
(892.53 KiB) Not downloaded yet

As was to be expected - it's still the same thing...
raaar wrote: 01 Apr 2021, 02:34 regarding the 3do -> s3o conversion, I've made a test a few hours ago: converting a 3do to s3o using upspring and testing it ingame.

Upspring has an option to generate a texture atlas .bmp image, but it'll contain only the textures used on the unit, not all textures on the texture directory, so different units will have different atlases (inconvenient).

The unit showed up textured on upsring, but when i saw it ingame, it showed a flat blue texture and the model was rotated backwards. I also remember some issues editing models using upspring vs using the 3do builder, i think the flat colored faces were somehow incompatible.
I tried this for myself too:
screen00017.jpg
(1.05 MiB) Not downloaded yet
I think the right one was the s3o and the left one the 3do. The overall color tint happens due to the teamcolor. The 3do->s3o texture converter just puts all the textures into one bitmap. Texture 1 for s3os has the teamcolor information in the alpha channel so you have to create an alpha channel for the texture where you paint the areas that should have teamcolor white and save it e.g. as a png instead of a bmp...
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

In the s3o screenshot the goliaths aren't textured correctly, it just looks like a blue blob, this is not acceptable for use in mods. Goliath texture needs to be applied correctly if you want to demonstrate how easy it is and make a fair comparison.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

I begin to get the feeling that you actually don't know what you're talking about and didn't really get what 3do and s3o means in terms of the technicality behind it. So here you have a final close up:
screen00018.jpg
(1.03 MiB) Not downloaded yet
3do is on the left (the "ugly one"), s3o is on the right. So as you see the s3os are textured correctly and for the 3do I just applied different textures to different parts of the model uniformly. So yes, both models are textured just fine - the 3do goliath having an ugly look is self-evident but this is not a beauty contest but a comparison of performance...
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

you are already complaining at the prospect of texturing 2 tanks

imagine how every mod feels who has to do this 400 times, for equal or lower perfomance than what they already have
User avatar
Hoi
Posts: 2917
Joined: 13 May 2008, 16:51

Re: Keep 3do model support

Post by Hoi »

3do model support exists because 20 years ago, the spring engine was meant as a kind of "TA 3d".

Now, the goal of spring is to make a general purpose RTS engine.

What purpose does it serve to keep support for these age old file formats, except to pander those who want to keep using copyrighted assets from a game released in 1997?

If you want to keep things like 3do in the spring engine, nobody is going to want to develop the engine. Because keeping the code compatible with these kind of relics can be very hard, and it may limit a lot of possibilities for new features. Developers want to work on new and exciting, modern features. They don't want to spend their time supporting file formats from the stone age.


Trim the fat. Remove 3do in the near future. Let's make sure the tools to convert to s3o work nicely, and a reasonable tutorial is available for those who need it.

You still want to use 3do? Nobody prevents you from using an old release of spring that supports it, or to code the support yourself into new releases.

I don't want to mention anyone by name, but the crowd that tries to frustrate progress because they are frankly, too lazy to do the minimal work to be up to date, the crowd who want to block every change and update for the sake of keeping everything the same... they should be passionately ignored.



If the topic is still so hot, I suggest a vote. But perhaps limit the voting rights to the (ex) engine devs who have contributed a lot. I am quite certain, they would agree and think it is in the best interest of spring, to mark 3do support as obsolete, and to remove it (after a short transitional period if needed).
Ares
Balanced Annihilation Developer
Posts: 555
Joined: 19 Mar 2011, 13:43

Re: Keep 3do model support

Post by Ares »

Hoi wrote: Nobody prevents you from using an old release of spring
viewtopic.php?f=1&t=39689
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

Is there any documentation online on the structure of 3do and s3o files? I couldn't find it.

This can be useful for us to write our own converters from 3do to another format that match our "production rules".

At some point i was wondering about renaming a texture file and updating all the .3do files through a command line script, but couldn't find a way.

EDIT: found some info here:
https://www.tauniverse.com/forum/showthread.php?t=45964
saturnV
Posts: 107
Joined: 03 Dec 2020, 07:58

Re: Keep 3do model support

Post by saturnV »

raaar wrote: 01 Apr 2021, 02:34Upspring has an option to generate a texture atlas .bmp image, but it'll contain only the textures used on the unit, not all textures on the texture directory, so different units will have different atlases (inconvenient).
This seems relevant. Does the other converter tool work the same?
As I understand, 3do uses one shared texture for all models.
If the converter generates one new unique texture for every model then that means texturespace goes up...by a lot?
For one converting one 3do to s3o it is not relevant but when converting the 200 models of a complete games it means increased texture space, more vram usage etc.
That also means benchmarking one 3do vs one s3o model does not tell so much.
Also I am not sure if the generated 3do-Goliath model is a good benchmark because it has much more polygons than a typical 3do unit.

Ares wrote: 01 Apr 2021, 16:08
Hoi wrote: Nobody prevents you from using an old release of spring
viewtopic.php?f=1&t=39689
It really is strangge how people STILL say these clearly wrong things.

If removing 3do really gives so big advantages (clearer code, performance, whatever) then remove it from future engine versions, if nessecary.
However, the possibility to play previous engine versions should always be there.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

You can have a look at the kinboat source too for 3do (or TA in general) related stuff:

https://files.tauniverse.com/files/ta/u ... rce-files/

As well as of course the source code of the Spring engine and upspring. Unfortunately 3dos aren't pure textfiles making reading them a bit more complicated but the TA community e.g. as you showed (I think the file also is present in the kinboat source) figured out pretty well how the structure works...
Also I am not sure if the generated 3do-Goliath model is a good benchmark because it has much more polygons than a typical 3do unit.
Well the question was to benchmark the rendering performance and so I chose a model with lots of polygons so 1000 instances of that model have more of a performance impact than a more simple one. I still didn't get any criticism implying that the results I got are faulty. The statement Ares made was about a 6x higher performance for 3do models. I cannot confirm that and my guess is that he compared 3dos with standard rendering with BAR's shader supported rendering which of course is way more demanding but has nothing to do with 3do vs s3o. Also in addition to that 3dos don't need to be as simple as most of them are:

https://www.tauniverse.com/forum/attach ... 1593796519

https://www.tauniverse.com/forum/attach ... 1601142460
saturnV
Posts: 107
Joined: 03 Dec 2020, 07:58

Re: Keep 3do model support

Post by saturnV »

Well the question was to benchmark the rendering performance and so I chose a model with lots of polygons so 1000 instances of that model have more of a performance impact than a more simple one.
The question is, how that benchmark compares to actually playing a game.

3do-Models do not have lots of polygons and in games there are never 1000 instances of the same model.

For example, lets assume that 3do-models are very ineffective when they have a high polygon count. That would make them a very bad format, but only on paper. In pratice it might simply not matter because the typical 3do-models are quite low poly.

Then there is the mentioned question of how one shared texture (3do) compares to hundreds unique textures. (s3o)
Especially on lower end system without much vram.
Also in addition to that 3dos don't need to be as simple as most of them are:
Ok, but those are not the typical 3do models found in currently played spring games.

ivand wrote something that switching between rendering paths has a cost per draw-frame.
That sounds like the worst-case situation is a mix of s3o and 3do models?
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Keep 3do model support

Post by ivand »

Despite my triple request to permaban me, I'm still here, so I can comment.

Ares is pretty incompetent as far as programming goes and totally incompetent when he talks about rendering. But worse than that he likes to toss the facts. Comparing perf of two games and making that s3o is worse than 3do out of it is quintessence of incompetence and cunning nature.

In the end assimp, s3o and 3do models are just triangles of attributes (position, color, UV, normals, etc). They can't be rendered slower or faster by definition. What can slow things down a little bit is switching of so called fixed pipeline state. 3do state is different than the state of s3o/assimp, so switching implies a minor per-frame cost.

The real cost though is implementer's time and sanity. In addition to s3o, assimp and LuaMaterial implementation one has to also implement 3do. Things cannot be left as is, because the whole architecture needs to be changed:
* Drawing shall no longer be done with display lists piece by piece, unit by unit, bin by bin. Instead all eligible geometry shall be collected and drawn in one submission to the GPU. The hooks to do so are there and even available from Lua, but the way rendering in the engine is done prevents the implementation and should be redone, almost from scratch. What makes things worse is LuaMaterials. Instead of native integration this one lives its own life, has its own materials binning, own drawing callins, etc.
* Since the drawing method above shall use GL4 capabilities all shaders internal to the engine or external as LuaMaterials need to be updated to GLSL 4.20 level.
* Since we can't rely on many GPUs supporting bindless resources, I'll most probably deprecate binning by texture type and build internal atlas from all game supplied textures. Unfortunately only BAR does things properly by atlasing unit textures. It's hard to ask the rest of the games to magically update their approach to textures, so texture atlases will need to be built upon the game start. And here's where 3do strikes in the groin. 3do is atlas itself, so in order to implement automatic atlasing their atlas needs to be translated into the automatically built atlas. 3do atlas is different to what people call atlas nowadays. Remember sanity remark? Here it's.
* Since 3do requires different FFP state, 3do models cannot be rendered in the same submission as the rest of the model types, even if 3do atlas textures are moved to automatic atlas.

The above is only doable with support of the shaders (thus the preemptive removal of no-shader path in one of the BAR branches) and done more easily without 3do (thus another preemptive strike to remove 3do).

Hope it makes sense.

P.S. Oh yes and if you want proofs new technology can be better than the existing one launch your game on 105 and then launch it on "the develop" https://springrts.com/dl/buildbot/defau ... -ga8cf33a/ Disable luaui and luarules and spam say 500 units with cheats. Compare FPS. And the develop is far less advanced in how it renders the units than what I described above.
Last edited by ivand on 01 Apr 2021, 19:03, edited 4 times in total.
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Keep 3do model support

Post by raaar »

perhaps we don't need hundreds of texture atlases.

maybe there's a way to "trick" the converter to generate an atlas that's the same for every unit, like temporarily adding to it a piece with hundreds of faces, one with each texture, then removing it after the conversion is done. This would lead for an identical atlas image for every unit.

Then one could just edit all the models and change the reference to a copy of it : one for each faction instead of one for each unit.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Keep 3do model support

Post by ivand »

raaar wrote: 01 Apr 2021, 18:21 perhaps we don't need hundreds of texture atlases.

maybe there's a way to "trick" the converter to generate an atlas that's the same for every unit, like temporarily adding to it a piece with hundreds of faces, one with each texture, then removing it after the conversion is done. This would lead for an identical atlas image for every unit.

Then one could just edit all the models and change the reference to a copy of it : one for each faction instead of one for each unit.
This is of course a good idea. "Hundreds" and "atlas" don't belong to the same sentence. The whole purpose of atlassing is to collapse hundreds into a few.

I do hope that the conversion tool by Behe or some other tool can export and transform 3do atlas into a single entity and make converted s3o models reference the same texture(s). If not such tools need improvements.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Keep 3do model support

Post by Master-Athmos »

Just adding my point of view on a detail:

While using atlas textures is great I wouldn't focus on it as the holy grail for everything. I know BAR chose to use an atlas system for their unit textures and this is completely fine but I wouldn't say that this is the best approach as it comes at a price of less individual texturing and repeating patterns which even can port over into the geometry design (I'm thinking of e.g. bots with "metal makers" as heads if you know what I mean). While using an atlas wherever it makes sense is a good idea I wouldn't proclaim the use of an atlas for everything - especially not unit textures.

What I could imagine is encouraging to combine the textures of one unit into one file so the classic texture 1, texture 2 and now additionally texture 3 for normal maps etc. is put into one single file instead of being split into three. Now three textures might be an unfortunate number but things could be changed in a way that instead of using the alpha channel we'll create a texture 4 so that every texture is rgb only so that the new unit texture concept combines four rgb textures with the fourth one inheriting the information that once were stored in the alpha channels of the texture 1-3 so that we can create an atlas out of 4 textures which also would just need a DXT1/3 level compression as no alpha channel is needed anymore. This also would enable giving the info from the alpha channels more detail as with texture compression you had to decide if you want harsh or blurred information - putting this information into the classic rgb range removes dependencies of the compression algorithm...
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Keep 3do model support

Post by ivand »

By auto-atlassing solution I meant the one that goes over all textures in tex1, tex2, possibly normal map, makes this set unique (i.e. no duplicates by filename) and automatically builds internal atlas by splatting these unique textures onto multi-page array texture.

The process is completely hidden from game developers and only concerns engine guts, except that "%<unitdef>:0/1" textures will need to go and be replaced with ref to one array texture per texture type (tex1, tex2, normal).
Post Reply

Return to “Engine”