@paulp Unfortunately after looking at the Spine/SkeletonGraphic shader code, there is no equivalent to be fixed (there is no problematic division by texture or vertex color alpha). So I'm afraid the remaining problem must come from something else.

Do you have a screenshot available which shows the remaining issue? At which location does the problem occur, what is the object at the incorrect bloom area's center, which shader is this object using?

@paulp One more update, could you please test this version:

@paulp Bad to hear, thanks for the feedback.

To be sure we're on the same page: Are you testing with the exact same reproduction project that you sent us last, and play this in the Unity Editor play mode with active target being Playstation 4 or Playstation 5?

I'm asking to be sure you're not perhaps testing a more complex scene where other shaders are used, like additive or multiply shaders instead of the URP/2D/Spine/Skeleton Lit shader.

@paulp Could you please try this second modified version of the shader and let us know the results:

@paulp Unfortunately so far we were out of luck reproducing the issue on our end again. Nevertheless, below you can find a slightly modified version of the shader before I'm leaving the office for today, to hopefully speed up the process a little bit:

Tomorrow I will hopefully find more time, apologies for the inconvenience!

@paulp That's unfortunate indeed, thanks for the feedback. We will continue our investigations.

@paulp Oh dear, very sorry to hear that the issue still persists on Intel UHD hardware!

Could you please have a try with this modified shader version and let us know whether it resolves the issue:

@paulp We have just pushed a bugfix commit to the 4.2 branch which should fix this issue.
EsotericSoftware/spine-runtimes2574
You could integrate the shader changes of the above commit to your 4.1 package installation. Note that the commit fixes a second files, which is an include file used by the other URP 2D shader Universal Render Pipeline/2D/Spine/Sprite.

You can also find the modified file for your 4.1 URP package below:

Please let us know if this fixes the issue for you as well.

Issue ticket URL for later reference:
EsotericSoftware/spine-runtimes2574

@paulp Thanks for the info! This seems to be confirming that the issue is due to special handling of undefined behaviour. We will continue our investigations.

@paulp Unfortunately I had no luck reproducing the issue today either, neither using the Universal RP package Misaki had installed nor the original one listed in the submitted project zip file. Could you perhaps have a try whether this reproduction project also reproduces the issue on your end when updating all involved UPM packages to the latest versions of the package manager? And after that, could you have a try whether the same issue still persists with Unity 2022.3.35 and the latest packages?

@paulp Unfortunately for strange reasons, while Misaki could immediately reproduce the issue, I could not yet reproduce it on my machine using either Unity 2022.3.18, 2022.3.35 nor the exact submitted version 2022.3.30 with Android being set as the active build target. I will get back to you as soon as I can reproduce the issue as well (hopefully tomorrow).

@paulp In general please never send unitypackages as reproduction project. Instead always send a zip package of your project, containing the important directories Assets, Project Settings, Packages. Unnecessary generated directories like e.g. the Library directory shall be deleted and not included in the package of course.

@paulp In general it is recommended to use BoneFollower components when you only need to follow a few bones and don't want to override bone locations. Having the whole hierarchy of SkeletonUtilityBone GameObjects comes with some overhead (having many GameObjects and SkeletonUtilityBone update cost). The only requirement is that a SkeletonUtilityBone with Mode Override needs the parent GameObject to be at the proper parent bone location. This can be achieved without the overhead of the whole hierarchy of parent bones by having just the parent bone of your Override SkeletonUtilityBone object as a BoneFollower GameObject.

So this hierarchy:

Bone1   [SkeletonUtilityBone - Follow]
  Bone2   [SkeletonUtilityBone - Follow]
    Bone3   [SkeletonUtilityBone - Follow]
      Bone4   [SkeletonUtilityBone - Follow]
        OverrideBone   [SkeletonUtilityBone - Override]

can be simplified to the following:

Bone4  [BoneFollower]
  OverrideBone   [SkeletonUtilityBone - Override]