Unexpected DhApiRenderParam#dhProjectionMatrix content with Iris enabled
I'm grabbing the projection matrix from the DhApiAfterRenderEvent and use it to perform a depth test in one of my shaders. And this works fine as long as no Iris shaders are active.
Usually the projection matrix contains "normal" values, e.g.:
But when an Iris shader is active (in this case BSL but I don't think it matters) the values seem wrong:
In earlier version of DH and Iris (1.x on 1.20.1 for example) this wasn't an issue.
It seems to me that DH is not providing the correct projection matrix, which is causing the depth test in my shader to produce wrong results.
I'm using:
- DH 2.1.2-a
- Iris 1.7.2
- Indium 1.0.33
- Sodium 0.5.9
and trying to update the DH compatibility of my mod "Better Clouds"
29 Replies
I hope you will find a fix!
bump
as @James Seibel (GMT-6) was the only one who could help you here: https://discord.com/channels/881614130614767666/1211290858134052894
i assume he's also the only one who can here you with this new problem
Yes, probably. But I'm sure he has a lot to do.
Thanks for the info I didn't realize there was a problem.
Hmmm... Iris must be modifying the matrix, which is causing it to change when passed along.
I have an idea on how to fix it, I'll add this to my todo list.
Thanks! Do you think it would be better to wait for the fix or look for a workaround on my end?
I just pushed a fix, please let me know if you're still having issues.
Awesome!
Do you have a dev-build at hand so I can test it out?
The latest nightly build has it
Oh, sorry I didn't realize you had nightly builds
No worries, just grab a build from #links-n-downloads
I can't test it out for now since Iris hasn't updated to the new DhApi version (afaik) and crashes since the math types have been renamed.
Makes sense, IMS has a test build for shader devs but I'm guessing it isn't public yet.
I'll try to make a local build of Iris which uses the new dh api
I've managed to patch iris and fix a crash related to the new LOD Clouds but using the 13363ff3 nightly build the projection matrix still isn't correct:
Update: just tested with todays nightly build afddf416 and the issue is still the same
I've finally had time to look deeper into the issue. Here are my findings:
renderLods calls renderLodLayer with the proper mcProjectionMatrix.
DhApiBeforeRenderEvent is fired
DhApiAfterRenderEvent is not fired because Delayed.renderProxy.getDeferTransparentRendering() is false.
renderDeferredLods calls renderLodLayer with an identity matrix for mcProjectionMatrix
DhApiBeforeRenderEvent is fired
DhApiAfterRenderEvent is fired using a dhProjectionMatrix derived from the identity matrix, which results in a not-really-useful matrix. I can't tell if thats right or wrong.
To fix my issue it seems that I can switch to DhApiBeforeRenderEvent and grab the projection matrix from there, since it contains the right projection matrix during the opaque rendering pass.
However I'm not sure the code in renderLodLayer is behaving correctly. It seems odd to me that there are two DhApiBeforeRenderEvent but only one DhApiAfterRenderEvent fired during a frame.Very interesting...
Since the matrices are correct for the opaque layer, but not the deferred layer I'm going to assume that Iris is messing with the projection matrix before DH pulls it in. Not sure why that would be though.
When you say that the
DhApiBeforeRenderEvent is fired twice, do you mean the exact DhApiBeforeRenderEvent event is fired twice?
When deferred rendering is active the DhApiBeforeRenderEvent should fire for the opaque layer, then then the DhApiBeforeDeferredRenderEvent should fire for the transparent layer.oh, I missed the "Deferred" part of
DhApiBeforeDeferredRenderEvent and thought it was also a DhApiBeforeRenderEvent. So corrected: Two "before render" events are fired, one DhApiBeforeRenderEvent in the opauqe path and one DhApiBeforeDeferredRenderEvent in the transparent path. However only a single DhApiAfterRenderEvent is fired in the transparent path.mcProjectionMatrix is an identity matrix because you explicitly pass in one.
Ok, good that's exactly how it should be done.
The
DhApiAfterRenderEvent should only be called after all rendering is done.Alright, I guess that makes sense, but the discrepancy between the DhApiRenderParam of the before and after event is still quite odd
Oh dang it. I forgot about that.
I think in MC 1.21 the
renderSectionLayer started merging the model view and projection matricies, so that's why they're the same.
I remember that being quite annoying the first time I delt with that...Maybe the DhApiAfterRenderEvent shouldn't contain the DhApiRenderParam at all, or both. But none would be easier and less confusing.
As I understand is know this is the intended meaning of the events:
1. Opaque pass start
2. Transparent pass start
3. Rendering end
But the actual information of the events is:
1. Opaque pass start (using ABC params)
2. Transparent pass start (using XYZ params)
3. Transparent pass end (using XYZ params)
So the values passed to the after render event handlers doesn't match their "definition". Sorry it's difficult to express what I mean by that.
What do you mean bye ABC/XYZ params?
The DhApiRenderParam used for that pass
What's an ABC RenderParam?
I think I'm missing something
Changing the DhApiAfterRenderEvent definetly isn't required since it's really not a big issue once you know about it, but it would definietly be worth noting in the docs.
ABC as a name for the values contained in DhApiRenderParam, like renderPass and mcProjectionMatrix.
Oh, you're just saying the values are different, gotcha
yeah
Having thought about it, I think you're right. Including a RenderParam for the ending event is more likely to cause confusion than anything since the parameters can change if deferred rendering is enabled.
I've removed the parameters and I'll be pushing my changes soon.
Thanks for the help and sorry for the confusion
No worries