Double rendering of Armor with AzureLib
Got a report of Armor being rendered at the Curser when wearing armor or looking at armor when using my Geckolib fork AzureLib. After doing some digging, it seems to be down to this line here: https://github.com/AzureDoom/AzureLib/blob/1.20/Fabric/src/main/java/mod/azure/azurelib/renderer/GeoArmorRenderer.java#L281 and having Real-Time Shadows on.
Any suggestions would be welcome.
38 Replies
Hello @Head Developer , this issue effecting thousands of players in a consistant manner.
Could you reply to the github issue by shedding some light on the potential ways to resolve it?
Any armor or specific armor?
if it's specific armor i need a mod that causes it
It's any armor that's done using the GeoArmorRender (this is seen both in Geckolib itself and my fork AzureLib). Daedelus found it in his mod wizards and I was able to produce it with a test armor in my fork, I can push a version with that test armor if you'd like.
no, i can just put wizards in the dev env it's fine
just needed to know that
Alright! It's got a lot of dependencies just a heads up.
hm, it's saying it wants geckolib specifically
so maybe i will need that test build actually lol
Give me about 10 minutes here and I'll have it up on my maven for you!
I'm building your mod to make it easier to debug
so just source works
Ah, the test armor wasn't pushed to my github, let me do a branch for that real fast.
you can ping me when it's up
and i'll take a look
@IMS https://github.com/AzureDoom/AzureLib/tree/1.20-iristesting here you go! Just need to add Iris and Sodium to the runs mod folder (it's what I do anyway).
GitHub
GitHub - AzureDoom/AzureLib at 1.20-iristesting
Based off Geckolib but now just for my own needs. - GitHub - AzureDoom/AzureLib at 1.20-iristesting
https://www.complementary.dev/shaders-v4/ is the shader I'm testing with as well.
Complementary Shaders v4 | Official Site
Complementary Shaders Version 4 is the original Complementary Minecraft Java Edition shader pack based on Capt Tatsu's BSL Shaders. The goal of Complementary v4 is being good at everything. Performance, gameplay, beauty, compatibility; you name it. Complementary v4 will try to provide you with the most issueless experience possible within limita...
š
v4 is actually being removed on friday fyi
does it happen with reimagined?
Oh, let me test real fast
got the bug
this seems like a pretty standard case of shadows being rendered in the wrong image
though I wouldn't know why
lemme see what i can do
Alright!
this really doesn't seem right
why are you not just using the world tick?
That was something from both Gecko/Tslat. That's a good point though and I'll test that out.
either way, the issue seems to be
poseStack is retained from the shadow pass
It seems the core issue just lies with the fact you can't call render twice in one frame and have it work
and you need to do something with reRender
that won't work, because the shadow pass kinda relies on that idea
for some reason your armor is taking the shadow pass's PoseStack but nothing else
OK i think I know what's going on
somehow, you're grabbing the player's RenderBuffers in what should be a shadow call
this defers whatever you're trying to render to happen way later than it should
the getArmorFoilBuffer is what's replacing the correct RenderBuffers
which is why it seems like that's the bugClarification:
- AzureLib is a fork of GeckoLib
- The issue happens any armor is rendered using GeoArmorRenderer (from either AzureLib or GeckoLib)
- Wizards is specifically using GeckoLib.
wait
i think i fixed it
š
š¤
I can fix this in Iris, and AzureLib can also fix this
realistically it doesn't matter which one
so I'll just throw a fix into Iris
You are living god
Sweet, what's the fix?
Both of you
You're grabbing
mc.renderBuffers()
but Iris never updates that
it updates mc.levelRenderer.renderBuffersthis should fix it if i'm right
I can also PR a fix to AzureLib
The fix would just be call renderBuffers, which just requires an quick AW to fix I assume?
AW or mixin accessor yeah
This does not fix it, because
mc.renderBuffers is final
so you will need to fix it on your sideThat fixed it perfectly @IMS thanks again!
Thank you hedg hog for helping!
Wait hang on
so iris only patches one reference to render buffers
but doesn't patch others
even though they're the same object
?
Why should iris not be fixing that?
?
the minecraft class version is final
and it doesn't conform to logic
levelRenderer renders the level, and should have it changed
the other one doesn't
it's the exact same buffer
it's literally the same object
2 different storages for the same object yeah
point is if you're rendering the level you go to LevelRenderer
if it's the GUI, you actually don't want the replaced one
and use Minecraft
shouldn't it be made significantly clearer that iris replaces the default buffer getter then if that's the case?
lol
you're ghost-swapping the render buffers outright, but only in one place and not others, which is an invisible inconsistency
you're saying you're doing it intentionally to keep compatibility for other modders, but for other modders to even know that they'd basically have to get lucky or just outright guess iris is breaking something invisibly