Character model: use latest Minecraft skin format

[Calinou]

Currently, Minetest Game uses 64×32 skins instead of the more recent 64×64 skins that were introduced in Minecraft 1.8/1.9.

The new skin format allows for "overlays" on all body areas, not just the head, and allow for separate arm/leg texturing.

What about supporting it, and making it the default? I'm aware it will break existing Minetest skins, so a conversion tool is needed.

More information about Minecraft skin format

[benrob0329]

Why not just add support for 1.9 skins? They have more layers, and are compatible with most skin creators.

[Calinou]

Why not just add support for 1.9 skins? They have more layers, and are compatible with most skin creators.

Oh, I thought it didn't change after 1.8. I'm just saying we should use the skin format the latest Minecraft version uses.

[sofar]

This forces a change in character.b3d model, and makes all current skins broken.

Not a big fan right now, but it's certainly doable (and could even be done in a mod).

[tobyplowy]

@Calinou +1 from me :D

[benrob0329]

@sofar there could be two models, one for the old style skins and one for the new style skins, it could choose between them based on resolution.

[sofar]

@benrob0329 detecting skin resolution is extremely difficult in Lua, and requires external lua modules, so that's "not really possible".

[tenplus1]

Signs_lib has a function to read width/height of a PNG image that could easily be tailored towards skins: https://github.com/minetest-mods/signs_lib/blob/master/init.lua#L188

[stujones11]

There could be an option in minetest.conf to specify which format/model to use. I already have added 1.8 support to my 3d_armor development branch, the models are available here: https://github.com/stujones11/minetest-models/tree/master/3d_armor

[sofar]

Even with skin size detection I'd refrain from doing this. It's extra triangles, lots or transparency, doable in mods already, not backwards compatible and a hassle for server operators to change all skins, etc..

Not a fan, sorry.

[VanessaE]

Detecting the skin format is trivial - all you have to do is get H/V size of the skin image via the aforementioned signs_lib code and divide one by the other to determine the aspect ratio. If it comes up as 1:1, use a v1.8 model. Otherwise use the 1.0 model that we have now. That should handle any worries of backward-compatibility.

Meanwhile, the extra triangles are simply not enough to notice even on the slowest hardware, nor is the transparency. All new skins I keep getting from my servers' users are 1.8 format. I can't remember the last time anyone gave me an old-format skin.

Making a 1.8 skin work on a 1.0 model is trivial but it loses significant details in doing so (you just crop off the bottom half of the image).

[stujones11]

I am fairly neutral about adding this to mt_game but it certainly should not be rejected on performance grounds, the number of additional polygons here is totally insignificant. The only valid argument I see against adding this is that it could (and will) be done by a third party mod.

[paramat]

Meh i feel we should stick to our current format, it's a very simple job for players to chop off the lower half. Even if the performance reduction is not large it's still not justified. If at some point Minetest supports full body overlays then there's a reason to use it.

[stujones11]

If at some point Minetest supports full body overlays then there's a reason to use it.

It is not really up to minetest to support full body overlays, it would be choice of skin that would determine which layers are rendered transparent or otherwise. I do think custom skins are pretty much essential for public servers, however they are managed. By the same logic we should get rid of the 'hat' and 'cape' layers since they're not used in the default game.

[VanessaE]

@paramat 630 skins in my current archive (every one of them a player's request) disagrees with your "very simple". One image is simple to trim. Hundreds are a time-waster for me, and if I don't do it, it upsets my users.

[stujones11]

If this were to be done then I think mt_game should simply upgrade to format 1.8 and be done with it. Checking image sizes and maintaining two separate models is out of the question IMO. This, however, does still leave us with the problem of existing server skin databases. Bundling a simple conversion tool as @Calinou suggested is one possible solution but something like this would need to be done around a version update.

[VanessaE]

Bundling a conversion tool when it could be handled rather trivially in the code makes no sense to me :frown:

[stujones11]

@VanessaE does that signs_lib code not require that the image file is stored within the mod directory?

[VanessaE]

If I remember correctly, when the server puts the texture into actual use, it just needs to be stored where Minetest normally looks for them, mods dir, game dir, server texture pack, etc.

However, signs_lib uses a file-open call, so as far as I know it doesn't matter where the file is, as long as you can supply a valid path to it. Mod security will probably interfere with that, though.

[stujones11]

Mode security will probably interfere with that, though.

That is what I am suspecting, so not that trivial. On the other hand, having an api feature to read texture dimensions would be a very useful thing in general but I guess that's another topic.

[VanessaE]

Actually, I wonder if mod security matters at all, since you can request an "insecure" environment from within a mod. In my opinion, this feature belongs directly in minetest_game as a helper function of some kind, so one would do that request in the "default" mod. Or perhaps add a separate "skins" mod to do everything related to this feature.

I would think that mod (whichever it may be) can then be whitelisted in minetest_game's minetest.conf.

[paramat]

One image is simple to trim. Hundreds are a time-waster for me, and if I don't do it, it upsets my users.

The players should trim their Minecraft skins, it's very easy, and reasonable because this is not Minecratt. If they're too lazy or get upset they're not worth having on a server, it's a nice little filter for higher quality players. Or, if they're very young and unable to use Gimp to trim they can get help from a relative to do so. I feel you should stop worrying about upsetting low-quality players, or those who demand to be spoonfed.

[paramat]

The thing to do is add some auto-trimming code to skins mods.

I feel this request is another example of being too concerned with the expectations of Minecrafters, we are not a direct drop-in Minecraft substitute. If we decide to add support for full-body overlays let's consder that independently without thought to what Minecraft is doing.

[stujones11]

we are not a direct drop-in Minecraft substitute.

We do claim to support minecraft skins, albeit a completely out-dated format. It would be foolish to not support the massive amount of freely available skins there are for minecraft.

[sofar]

Skin support in minetest is already terribly bad (users can't add their own skins, new skins require a server restart, etc.). This change would just make it more complex. I'd rather fix the two aforemented problems first, and then this problem, the other way around would just complicate things I think.

[VanessaE]

tl;dr: @stujones11 is right, if Minetest is going to claim to support Minecraft skins, it needs to support at least the current 1.8 format. Either switch models as needed based on the chosen-skin's aspect ratio, or use only a 1.8-compatible model and pad the skin with transparency at load time to make it fit. Those are the only two choices that make any sense - anything else would just be too hacky.

@paramat, in my experience, about 80% of the Minetest user base are children on tablets or smartphones, mostly between roughly 7 and 14 years old, who don't know that they can copy and paste a URL, let alone actually being able to download and edit/crop an image and upload the result somewhere. There's a reason a server generally has a few admins and a bunch of users, rather than a bunch of admins and few users, and it's not for bragging rights.

Furthermore, while cropping the image makes the skin technically compatible with the current pre-1.8 model, doing so deletes important details from the skin, making the idea wholly inappropriate for an upstream "solution". Meanwhile, players occasionally notice that the cropped skins look wrong without the extra details, and when they do, they either complain or they go find another skin, prompting another cycle of explaining how to copy & paste a URL, repeating till they get it right, download to my PC, edit, upload to server, and wait for the next scheduled restart/see if they like it. The simple fact is, nearly every Minecraft skins website supplies only the 1.8 format now, and in a production environment (if such a phrase even applies to a game), every damned player wants a skin. I think I speak for every Minetest server admin out there: we're getting tired of the hassle. Where's the fun?

Also, the standard Minetest model only has 96 polygons, or so says Blender. Adding overlays for 1.8 compatibility and for things like armor would put the model at less than 300 polys, assuming a total of two overlays are necessary (I'm not sure of that detail). For comparison, the original Quake (1996) had a 200-poly player model (with a 320x200 skin). Quake 3 (1999) had between 500 and 1500 polys, depending on what source you take as authoritative (I'm not sure of the skin resolution). That's statistical noise compared to the hundreds of thousands of polys that is the world surrounding the player(s). Even 100 players with those 300-poly models would still be only a small fraction of the visible poly count - practically statistical noise - and that's if you could manage to get them all on-screen at once and keep the server from melting down in the process. :smile:

All of this aside, no one is claiming Minetest is a "drop in replacement", but if it claims to support a Minecraft feature, it needs to support it fully or the feature just looks broken to everyone who isn't specifically aware of the decision behind it. That also means that the way capes are handled needs changed (to use a separate image file), since it violates both Minecraft skin formats.

@sofar, the two issues you mentioned are independent of skins/player models - the same could be said for node textures, dropped items, or MOBs as well. What you're proposing there is surely a far more difficult change, with security and social implications (think malicious files, graphic imagery, nudity, etc), with far less actual benefit. The skin format problem can be fixed in code the right way very quickly. Don't let "perfect" be the enemy of "good".

I have to say this, guys: this is yet another user-facing item that needs addressed, but instead, you are obsessing over everything else except what the user is seeing! It's upsetting users (which includes me, as I do actually play from time to time), and it's making more work for server admins.

If I were so inclined, I would just fix this myself and submit a pull request, but I don't do animated models, and you guys will just ultimately reject it anyway, making the whole endeavor a waste of my time. In the time it took any one of you to read this thread for the first time, and hell, just in the time it took me to write this one post, someone could have already made an appropriate model and changes to the Lua code, issued a pull request, and deployed the changes to a public server for testing.

[paramat]

Capes were a bad move, they are super-exclusive to Minecraft / Minecon so very tasteless to add those to Minetest, they should be removed.

[ghost]

I agree about removing capes. Unless they "flowed" as real cloth does. As they are now they resemble a hinged sign you'd see some fool wearing on a street corner advertising hot dogs or something. Back to the topic... I'm hoping we become compatible with 1.8 skins. There are piles of very good MC skins out there that can be used, and it would be nice to take advantage of them.

[stujones11]

Added a forum poll: https://forum.minetest.net/viewtopic.php?f=5&t=15387

[paramat]

VanessaE some good points. I also misunderstood this request, certainly we can consider full-body overlays, i'm neutral currently.

[pinkysnowman]

i could make a model for the 1.8+ mc skins and code it to work the same with older skins as well :3 thats easy af, but ehhh do i even care is the question rn.

[stujones11]

i could make a model for the 1.8+ mc skins and code it to work the same with older skins as well

Sadly, that is not possible or I would have done so already.

[pinkysnowman]

well sadly it is very possible and you must have overlooked some basics in lua :3

time for the teenage girl to show the boys how its done

coding.................

[stujones11]

To clarify, I mean that it is not possible with a single model, at least not without changes to the engine.

[pinkysnowman]

and why isn't it???? as im doing it right now in blender!!!

[pinkysnowman]

well........ the model is done and has mc 1.0 and 1.8+ skin ability and retains the cape as well :P

Now for a few lines of code..... but should the default game have the code to run both types as most never change their skin?

[pinkysnowman]

currently testing a number of new skins to make sure there are no bugs!

[sofar]

@pinkysnowman

time for the teenage girl to show the boys how its done

This is completely inappropriate. Try and refrain from comments like this. You're making it personal, and it isn't - it's a technical discussion and we should keep it that way.

[sofar]

It just occurred to me that one could use our texture manipulation functions to solve the issue in a backwards compatible method (I think).

MT skins are 64x32, new ones are 64x64. We could detect the size in lua but it's expensive and requires likely to read the PNG headers in lua over and over again.

We could use a texture overlay and force all textures to 64x64 by creating a 64x64 "blank" texture and overlaying the actual texture on top of that - unmodified in size. That would make the resulting texture always 64x64, no matter the format - no lua needed, except from the texture definition in the player object.

[paramat]

Nah, her comment is ok :] Meant in good humour.

[stujones11]

@sofar overlaying the texture like that will result in the character having only one arm and one leg. You would need the equivalent of this: https://github.com/stujones11/skin-converter done somehow in Lua to convert the skins properly on-the-fly.

[sofar]

Ah, I see, the new format is 2:1 and not 1:1. The method could still work, though (it may be more complex than I stated, ofc).

[stujones11]

@Calinou linked the specs in the top post, as I see it they are 1:1 typically 64x64 pixels. Version 1.8 simply extends the 'hat' layer to the entire body and gives you independent texturing of the left and right limbs.

[VanessaE]

Minecraft skins are not exclusively 64px wide, and Minetest already supports high-resolution/"HD" Minecraft skins just as a function of its normal texture handling.

To figure out the type of skin, you HAVE to figure the image's aspect ratio and pad the image properly at load time, or switch models as needed. I don't think you can use texture compositing operations in Lua, they're too locked to image resolution. Do it right, don't kludge it.

[pinkysnowman]

I have working code and the model for it, I am a busy girl so if you guys chill out, and get a bloody sense of humor @sofar, I can finish testing and post it up..... :3

[pinkysnowman]

@VanessaE my code is compatible with any hd skin :D you know mine is HD, i can't break my own skin lol :P

[C1ffisme]

@sofar

@pinkysnowman

time for the teenage girl to show the boys how its done

This is completely inappropriate. Try and refrain from comments like this. You're making it personal, and it isn't - it's a technical discussion and we should keep it that way.

Eh... It's not the worst thing that this issue tracker has produced.

[stujones11]

Minecraft skins are not exclusively 64px wide

I thought 64px was the actual limit for MC skins though I may be mistaken. Nevertheless, the conversion tool I made will work fine with HD images but maybe not so well with npot dimensions

[paramat]

@pinkysnowman we'd like to see your code and model if you were able to finish it.

[stujones11]

@paramat I can supply a 1.8 format model (with or without cape) but will not be making a PR. The limited poll results would suggest that most people would like this but would also want backwards compatibility with the existing skins and I fail to see how that would be possible without maintaining two separate models.

[paramat]

Yeah more discussion is needed.