You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
While looking at Fresh Moves and ETF, I realized a problem with sustainability for player models. As more and more features are added, more and more space is required.
This problem is unique to player models, since they're restricted to Mojang's definition of the player texture. You can't define a new texture, because then every player would use the same texture.
EMF especially suffers from this, as there's no way to "encode" data into the image like ETF does (and even that mod isn't perfect with it, but it's held to its reverse-compatibility promise).
Describe the solution you'd like
A way to sample the color of a part's texture in animation, perhaps as a function like colorAt(some_part, x, y). The color itself would then have r, g, b, and a properties. Ideally, along with this feature would be bitwise operators (&, |, ^, ~) to enable packing efficiency, but it's not a hard requirement.
Does OptiFine do this
No.
Additional context
As mentioned in the summary of my problem, this mainly came from investigating Fresh Moves and ETF. Why I started investigating is because my player skin has unique 2x2 eyes that don't follow the assumption Fresh Moves makes. Fresh Moves is already packed to the brim, and there's not much space left that wouldn't conflict with ETF.
I figured that if there was a way for the model to check some pixels for their color, then it could be combined with other existing features, such as the visible property, to greatly reduce the space needed for highly dynamic player customization such as what Fresh Moves wants to do with eyes. Even a single pixel for encoding the eye type would allow all of the UVs for the eyes to collapse into a corner, sharing the same space, since the color could be used to set the visible property on the correct eye parts.
The text was updated successfully, but these errors were encountered:
Agree. That would be super useful for some of my projects too! Having an animation function for getting texture color of the pixel would be really cool
Is your feature request related to a problem? Please describe.
While looking at Fresh Moves and ETF, I realized a problem with sustainability for player models. As more and more features are added, more and more space is required.
This problem is unique to player models, since they're restricted to Mojang's definition of the player texture. You can't define a new texture, because then every player would use the same texture.
EMF especially suffers from this, as there's no way to "encode" data into the image like ETF does (and even that mod isn't perfect with it, but it's held to its reverse-compatibility promise).
Describe the solution you'd like
A way to sample the color of a part's texture in animation, perhaps as a function like
colorAt(some_part, x, y)
. The color itself would then haver
,g
,b
, anda
properties. Ideally, along with this feature would be bitwise operators (&
,|
,^
,~
) to enable packing efficiency, but it's not a hard requirement.Does OptiFine do this
No.
Additional context
As mentioned in the summary of my problem, this mainly came from investigating Fresh Moves and ETF. Why I started investigating is because my player skin has unique 2x2 eyes that don't follow the assumption Fresh Moves makes. Fresh Moves is already packed to the brim, and there's not much space left that wouldn't conflict with ETF.
I figured that if there was a way for the model to check some pixels for their color, then it could be combined with other existing features, such as the
visible
property, to greatly reduce the space needed for highly dynamic player customization such as what Fresh Moves wants to do with eyes. Even a single pixel for encoding the eye type would allow all of the UVs for the eyes to collapse into a corner, sharing the same space, since the color could be used to set thevisible
property on the correct eye parts.The text was updated successfully, but these errors were encountered: