Description

Hello,
This issue is present since the feature to turn player transparent has been added.

The problem essentially: any non vanilla feature renderer gets rendered as opaque, while the player is transparent.

Attachment shows:

• Wizard Hat (from Wizards mod), custom modelled armor, rendered by AzureLib Armor
• Cape rendered by Wavey Capes

I respectfully ask for a resolution of this issue, as it would greatly improve QoL ingame.

Minecraft version

1.21.1

Incompatible mod name

Wizards + AzureLib Armor, Wavey Capes

Incompatible mod version

All :)

Game Logs

https://mclo.gs/59nf5P4

As a layman, I see 2 approaches to resolve this:

1. Expose the custom alpha that Shoulder Surfing produces via an API, so other feature renderers explcitly use it.
2. Make the modified alpha somehow reach the render code of other feature renderers.

Maybe there are even more options in general. As my render related skillset is very limited, I leave such conclusion to the grand masters of rendering. :)

Thanks for reaching out!

Expose the custom alpha that Shoulder Surfing produces via an API, so other feature renderers explcitly use it.

This is already done. Other modders can depend on the api jar of Shoulder Surfing Reloaded and obtain the custom alpha value by calling:

float alpha = ShoulderSurfing.getInstance().getCameraEntityRenderer().getCameraEntityAlpha();

The value will only be set to the correct alpha value while rendering the camera entity, otherwise it will be 1.0.

Make the modified alpha somehow reach the render code of other feature renderers.

This is a bit tricky, as two criteria need to be met:

1. The render type of the object being drawn must support transparency. For example, Wavy Capes uses the render type entityCutout, which does not support transparency.
2. Some mods (for example, Sodium, EMF and Skinlayers) provide their custom implementation of ModelPart[.Cube], hardcoding the alpha value to opaque. To my knowledge, this is the last possible step to in the pipeline to change the alpha value before rendering. Technically, all calls to VertexConsumer.addColor() need to be adjusted, which is not possible, as mixins do not allow for modifying default interface implemetations, and custom VertexConsumer implementations will not be covered anyway.

I added some new API methods to ICameraEntityRenderer in 3bfdf64:

/**
 * @return true when render thread is currently rendering the camera entity, otherwise false.
 */
boolean isRenderingCameraEntity();

/**
 * @return the value of getCameraEntityAlpha mapped to integer interval [0, 255]
 */
boolean getCameraEntityAlphaAsInt();

I also made a change to getCameraEntityAlpha, which now always returns the camera entity's alpha value, regardless if the render thread is currently rendering the camera entity or not.