spraxdev / api.sprax2013.de Goto Github PK

Original repo: https://github.com/googlecreativelab/teachablemachine-community
Example change: https://github.com/googlecreativelab/teachablemachine-community/pull/90/files

Is your feature request related to a problem? Please describe.
-

Describe the solution you'd like

• Rendering Blocks as they appear in the vanilla client (inventory and placed)
• Support for different Resource Packs
• Support for different versions (https://mcasset.cloud/)
• Support for file-upload (texture)
• Support for blocks with multiple faces (eg. Furnace with front, side, ...)

Describe alternatives you've considered
MineRender allows rendering GUIs. Sadly only Client-Side and Block-Items are not rendered 3D as the vanilla client does (maybe create PR when renderer is done?)

Additional context
-

Describe the bug
When you have a skin with transparent pixels (e.g. ) in the first layer, it is no longer being rendered as the minecraft client does.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://api.sprax2013.de/mc/skin/x-url/body?size=128&url=https://cdn.skindb.net/skins/2297506840247797003 or https://api.sprax2013.de/mc/skin/x-url/body/3d?size=128&url=https://cdn.skindb.net/skins/2297506840247797003 for the 3d-version

Expected behavior
The first skin layer should be put 100% non-transparent for 2d and 3d version. Maybe add a function to the Image class to return a new image that removes alpha from the first-layer

Screenshots, Videos, Logs or Errors

Fix duplicate code introduced in #64

Describe the bug
The 2D Renderer has problems with skin overlays having an alpha of below 100% replacing the pixel underneath it instead of still showing the one below.

The 3D Renderer has a simillar problem, where rendering such overlay, not showing what's behind that pixel.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://api.sprax2013.de/mc/skin/x-url/body?url=https://cdn.skindb.net/skins/2258170679830512715 and https://api.sprax2013.de/mc/skin/x-url/body/3d?url=https://cdn.skindb.net/skins/2258170679830512715
2. 2D version has white (transparent) pixels around the goggles (less than 100% alpha, but fully replacing the pixel underneath it)
3. 3D version has a large transparent area around its neck that should not be there

Cache skins on drive to reduce traffic and speed up response time for known skins

Every skin requested for rendering should be imported into the database if required and fetches from the database instead of downloading them.

Why?

• Reduces Traffic
• Improves response time
• More skins for SkinDB \o/

Why not?

• Skins may have been deleted my Mojang so maybe we should check if they have been deleted and return 404 but that shouldn't be that much of a problem when it is introduced afterwards.

/skin/:user? and /skin/:user?/:skinArea? should be able to respond with an 3D version

request has been discontinued.

Maybe consider https://www.npmjs.com/package/cached-request (fork or own implementation?)

Describe the solution you'd like

• Show the full path that is expected so the user knows not only what argument is requred but where it belongs (e.g. /mc/skins) can be confusing if you don't know where the username is supposed to be or the area you want to have rendered.
• Maybe a link to documentation to get more information about the used route

Own database should be prefered over the fallback api (should be faster and more reliable)

Describe the bug
Some skin parts are rendered wrong in the 3D version as they are getting mirrored.

To Reproduce
Take a look at the face. The front of the body is falsely mirrored too but I can't find an example for that at the moment. 2D Version is how it is supposed to be looking.

3D Version (src-1, src-2):

2D Version (src-1, src-2):

Original (src-1, src-2):

SkinDB ist nearly finished (included in Api.Sprax2013.de) and I just feel like the current version of the Mojang-API-Mirror or just Mojang-route of my api, is not as great as it could and should be.

Release v1.0 includes:

• Recode in TypeScript for better readability and maintainability.
• Rename routes ('/mojang' for example to '/mc') because it only contains Minecraft related stuff and would get too large if other stuff is added there too.
• Automatically store everything minecraft related into a database for caching and projects like SkinDB
• ...

And while at it:

• improve performance and response time
• Minimise the need for external Software (e.g. SkinDB-Backend or dependencies)
• Introduce detailed monitoring to my edge server (not Api.Sprax2013.de) for better analysis of what could be improved.
• ...

See the full list at #44

OptiFine sometimes has troubles too but LabyMod a noticeable lot more.

Bot services got trouble keeping their SSL and DNS running and up-to-date... Sometimes their servers are down.

Things happen, but the API should not have troubles and deal with these errors to reduce spam-like error reporting and not affect response times too much.

This requires the documentation to be updated to cover for cases where data could not be fetched but the most important did (= HTTP Status 200).