Compatiblity Issue with Distant Horizons
ColdIce1605 opened this issue · 40 comments
What happened?
With shaders enabled chunks in that where apart of the lod didn't render.
Screenshots
Relevant log output
NO relevant logs.Minecraft Version
1.18.1
Iris Version
iris-mc1.18.1-2.0
Sodium Version
sodium-fabric-mc1.18.1-0.4.0-alpha6+build.14
Operating System
Linux
What is your GPU?
1050ti
Java Version
Java 17
Additional context
N/A
Distant Horizons is using custom shaders: https://gitlab.com/jeseibel/distant-horizons-core/-/blob/main/src/main/java/com/seibel/lod/core/render/LodRenderer.java
Iris cannot support that out of the box: https://github.com/IrisShaders/Iris/blob/trunk/docs/development/compatibility/core-shaders.md
It's certainly possible to make the mods compatible because Distant Horizons seems to just be using shaders for its custom vertex format (Iris already has tons of custom handling for what Sodium does), but it doesn't really seem like anyone is interested in investigating compatibility between Iris and Distant Horizons right now.
It would certainly be a lot of extra code on our side since we don't have anything general for accommodating these things (but I plan to make things more general in the future). It doesn't really seem like Distant Horizons has much of the extensibility required to actually accommodate compatibility with shader mods either - everything's seemingly fairly hardcoded to the samplers, uniforms, and framebuffers it specifically needs.
I don't plan to investigate this further in the near future until Distant Horizons has stabilized and has better extensibility here.
Hello there! Is there a possibility to make latest dev ver. of bliss shaders and DH work together on 1.19.4?
Distant Horizons dev team here,
Currently we don't have anyone who has really written shaders before or knows how Iris works. And while our current system is mostly hardcoded, in the future I hope to get a new renderer working which would support the Iris pipeline. But, I need some help understanding what we would need to change in order to support Iris.
Rough overview of our rendering system
First and foremost: we don't touch the vanilla rendering system. We use a skybox method for rendering, very similar to the source engine (HL2, TF2, CS:GO, etc.), so everything we render will show up behind what vanilla Minecraft renders.
Specifically, we inject our rendering after minecraft renders the skybox (right before the clouds and chunks). When rendering we use a custom projection matrix with the near clip plane starting as far as possible before it leaves the vanilla render distance and a far clip plane based on our lod render distance. After rendering somewhere around 100,000 quads, we clear the depth buffer and let Minecraft render on top of us.
Vertex Format
Our vertex format includes: a pos, color, block/sky light value, and UV coordinate for the lightmap texture. Currently UV mapping is not supported and I'm not sure if it could be supported due to how much we've tried to compress the vertex buffers. (Generally our buffers reach about 1 GB in total, however on high settings we've seen usage as high as ~4 GB.)
GL Contexts
One other thing to note is that we use multiple contexts, due to the size of our buffers and our focus on multithreading.
Currently we have 2 contexts; one for uploading/creating buffers and a second one for running cleanup calls asynchronously (maybe not necessary tbh). Is this something Iris can support? We haven't looked into it yet.
Iris support
Vertex Format issue
Adding a uv mapping coord may be possible further down the line when we optimize the meshing. Potentially by replacing the color with an index to a texture generated by us. This system could support multiple texture mappings per block. However, we have ruled out using Iris' full vertex format due to it being too large, and we have also decided to impose a limit of 1 color/pixel per block. (i.e. even with texture mapping, a block can only use a single pixel for color since there is no UV mapping provided. Multiple texture sampling could be supported however.)
Frame buffers support (or lack of support)
If you are wondering what frame buffers we are rendering on, well.... We have no idea... I only recently noticed the issue, and I'm still figuring out what frame buffers are in use and stuff like that. How do or if iris use frame buffers to render?
Depth issue
Due to the fact that we are rendering like a skybox this can cause issues with shaders that require depth. Currently we only have one idea to partially fix the problem:
Use a render pass to transform the depth value back into the vanilla range. This will require a bit of math, but it's doable. However, since we are still limited to the vanilla clip planes, most of our lod terrain will be clamped to the max depth value. I have no clue if this would be better or not.
Current Plan/Idea
For our next major update our plan is to fix the bug where Iris prevents us from rendering anything and go from there.
I really want Distant Horizons to support Iris. But I'm not sure what would be our best course of action. What can we do on our end?
Any help or direction would be greatly appreciated,
- Lee Tom and Distant Horizons development team
Thanks for the detailed explanation. I can't currently respond to this in full due to a lack of time, but the framebuffer thing is intended behavior of Iris - it sees that a shader pack shader is not being used to render the LOD terrain, and prevents the content from being drawn to the screen to avoid confusing rendering issues. Most shaders expect that all things in the scene will use one of their provided programs (or a patched version), and Distant Horizons using its own shader program is guaranteed to produce incorrect results - but notably, inconsistent results across packs.
So nothing being rendered to the screen is intended, until it becomes possible for LOD terrain in Distant Horizons to be properly rendered using an Iris shader. But implementing that fully is very hard. We do something similar for Sodium, but it took quite a large time to build up all the code needed to properly work with Sodium.
This seems like a very difficult problem to approach, and the hard part is that there's no guarantee that a seamless transition can ever be achieved with the current status quo of shader packs. Shader packs handle skybox-type things pretty poorly, especially since most of them completely overwrite the vanilla skybox with their own effects.
The depth issue is certainly a challenge as well. How does Distant Horizons even handle that properly in the first place? Does it try to use a higher precision depth buffer, or does the projection matrix it uses scale the depth values differently?
Would it be possible to get an option to disable fabricskyboxes even when shaders are enabled? Getting it to show the lod at all would be 80% of the way to compatibility as far as I am concerned, since that would make this work for some use cases (e.g. vanilla-like shaders, and world curvature shaders which distant horizons already has as a builtin for rendering in the lod)
Would it be possible to get an option to disable fabricskyboxes even when shaders are enabled? Getting it to show the lod at all would be 80% of the way to compatibility as far as I am concerned, since that would make this work for some use cases (e.g. vanilla-like shaders, and world curvature shaders which distant horizons already has as a builtin for rendering in the lod)
Did you make any progress with this approach?
One of the Devs of Distant Horizons here,
Taught I'll put this note here so the Iris Devs know what's happening on our side
At the moment, Distant Horizons works with Iris but renders twice. Although, currently we cannot turn off the fog rendering from shaders. Would there be anyway to do that or would it be too much of a hassle as most shaders work differently in how they handle stuff like fog?
Corresponding issue on DH GitLab: https://gitlab.com/jeseibel/minecraft-lod-mod/-/issues/49
It might be possible to change how fog renders but it would be helpful to have a screenshot of the current state of the issue to validate that the issue is indeed fog rather than something else.
Shaders mostly control the fog so I don’t believe a mod can do anything about it, only thing I’m thinking is actually telling the shader a much larger render distance.
I'm not really sure how disabling fabricskyboxes would help, since the issue occurs without fabricskyboxes present. If you're instead referring to the various skybox effects added by shaders, the concern with an approach like that (assuming that there is a good way to implement it in the first place) is that it would lead to different behavior across shader packs, making it seem like it is an issue in specific shader packs that is logically the fault of those specific shader packs.
The other reason we haven't tried any of these imperfect workaround approaches is just an issue of time. There's only so much developer time available, and it's not clear whether it's worth it to go forward with workarounds rather than putting time towards a more ideal solution.
For that ideal solution, the most sane approach is probably creating a new gbuffers_lodterrain program that extends the gbuffers_basic program. This program would be invoked before all calls to gbuffers_terrain but after all calls to gbuffers_skybasic and gbuffers_skytextured. Some shader packs like Sildurs Vibrant Shaders make assumptions that gbuffers_terrain doesn't have anything else that comes first so they might break, but otherwise this should be viable.
The depth issue could be handled by rendering gbuffers_lodterrain with the different depth buffer as described, and then it should be feasible to carry this information forward by replacing any depth values (that are not the farthest possible depth value) with the depth value that is one less than the farthest possible depth value as a marker that there is indeed something present, since many shader packs treat the presence of a depth value as an indicator as to whether something is present at a given pixel location.
Just posting to thank you for working together on this issue, I am very much looking forward to be able to use Distant Horizons with shaders.
hey, for those still reading; Iris 1.7 has full compatibility with supported shaders.
Bumping this, as before: any way to turn off the behavior described would be a solution to this problem.
the framebuffer thing is intended behavior of Iris - it sees that a shader pack shader is not being used to render the LOD terrain, and prevents the content from being drawn to the screen to avoid confusing rendering issues. Most shaders expect that all things in the scene will use one of their provided programs (or a patched version), and Distant Horizons using its own shader program is guaranteed to produce incorrect results - but notably, inconsistent results across packs.
We don't need this to be full fat compatible to solve the problem (although that would be nice), we just want an option to turn off this extra check that is blocking the lods, intended behavior or not.
Screenshots for comparison as requested earlier in the thread. Any solution that preserves the lods instead of hiding them would fix the issue, since the far lods are low enough detail that shaders are unlikely to make much difference other than overall coloration.
I'm kinda curious- how come optifine supports it (apparently?) out of the box but iris doesn't? Or was optifine specifically updated to include support for it like it is now being requested/worked on for iris?
optifine does not support DH. pretty sure its the other way around, where DH edits/patches itself into optifine's shader stuff (idk exactly how. not a programmer)
DH technically does have iris integration (it was available in earlier test builds) but due to the way DH edited iris stability and compatability issues were present (most notably with shaders that use a certain type of rendering) so it was opted to remove that in favour of a proper solution. all the stuff on DH's side is there and waiting for iris to make the changes on its side.
tl:dr. optifine bad; DH has to beat it into submission. iris good; DH just asks it nicely but iris doesn't understand yet so will take some time to update it.
Actually it was Iris we had to create a hacky solution for rendering to happen. Since Iris removes anything that isn't rendered using their system we had to inject our rendering into Sodium, which Iris ignores, allowing DH LODs to appear. Whereas Optifine rendering has pretty much always worked right out of the box.
That being said, in both cases LODs often would render different than the vanilla chunks when shaders were enabled, so the transition between shaded MC chunks and DH LODs is often quite stark.
Actually it was Iris we had to create a hacky solution for rendering to happen. Since Iris removes anything that isn't rendered using their system we had to inject our rendering into Sodium, which Iris ignores, allowing DH LODs to appear. Whereas Optifine rendering has pretty much always worked right out of the box.
That being said, in both cases LODs often would render different than the vanilla chunks when shaders were enabled, so the transition between shaded MC chunks and DH LODs is often quite stark.
ah. fair enough. always interesting to see these sorts of glimphses into the inner workings of things :D
Iris removes anything that isn't rendered using their system
Huh that sounds... quite troublesome for mods that want to do anything fancy visually-speaking. Was this done for performance reasons, I imagine?
To provide historical context, It was not done for performance, but rather for ease of debugging rendering issues when Iris does not have an override for a given rendering program - as during and after the 1.17 port of Iris, that was common even for some vanilla content:
the framebuffer thing is intended behavior of Iris - it sees that a shader pack shader is not being used to render the LOD terrain, and prevents the content from being drawn to the screen to avoid confusing rendering issues. Most shaders expect that all things in the scene will use one of their provided programs (or a patched version), and Distant Horizons using its own shader program is guaranteed to produce incorrect results - but notably, inconsistent results across packs.
I am not really up-to-date on what the new Distant Horizons shader compatibility is or looks like, but at least at the time of last writing, Distant Horizons shader compatibility on OptiFine relied on shaders being OK with content rendered without shaders being placed in the first color buffer. That is why BSL and Complementary worked somewhat acceptably, and why things like SEUS and Sildur's don't work with DH particularly well. It's not necessarily that they are doing anything wrong, but rather that they just haven't designed themselves to be tolerant of invalid behavior from the side of the shader mod & other mods.
It's a tough decision to make, because essentially it's choosing between favoring shader developers (allowing random unshaded content into their color buffers makes their shader look broken and buggy), and (potentially) favoring the immediate wants of modders & users (by just letting something appear on the screen, at all), while the time is taken to sort out a proper approach to compatibility.
The reason why OptiFine appeared to work with DH 1.x in the past is that it really didn't think through that decision at all, and essentially just lets anything through to whatever shader color buffer happened to be in last use at the time. Which means that things show up on the screen, but I wouldn't necessarily call that proper compatibility!
So I am curious, is there any public documentation on the new DH shader compatibility in 2.0?
I am not really up-to-date on what the new Distant Horizons shader compatibility is or looks like, but at least at the time of last writing, Distant Horizons shader compatibility on OptiFine relied on shaders being OK with content rendered without shaders being placed in the first color buffer. That is why BSL and Complementary worked somewhat acceptably, and why things like SEUS and Sildur's don't work with DH particularly well. It's not necessarily that they are doing anything wrong, but rather that they just haven't designed themselves to be tolerant of invalid behavior from the side of the shader mod & other mods.
iirc its because of difered rendering vs forward rendering. both are valid options with their respective pros and cons. i think minecraft (and most real time stuff) uses difered rendering though im not 100% sure on that. i recomend looking into it but the gist is some shaders use forward and others use difered and depending on which will affect compatability. forward might be the more robust of the two? not certain.
So I am curious, is there any public documentation on the new DH shader compatibility in 2.0?
Due to shader devs actually requesting this, Iris 1.6.11 has a workaround to let DH’s content render into colortex0, ignoring the previous checks. It still applies these checks to other content.
Proper compatibility is planned, but due to multiple issues referring to deferred rendering we don’t have a full idea on what that’ll look like.
So I am curious, is there any public documentation on the new DH shader compatibility in 2.0?
Due to shader devs actually requesting this, Iris 1.6.11 has a workaround to let DH’s content render into colortex0, ignoring the previous checks. It still applies these checks to other content.
Proper compatibility is planned, but due to multiple issues referring to deferred rendering we don’t have a full idea on what that’ll look like.
Is the 1.20.x branch updated with this or only 1.18.x?
Should update this issue with the new shader compatibility in Distant Horizons 2.0. Currently shaders work with optifine, but need more iris support to work
I'm kinda curious- how come optifine supports it (apparently?) out of the box but iris doesn't? Or was optifine specifically updated to include support for it like it is now being requested/worked on for iris?
In the meantime wouldn't it be better to employ the same approach with iris (via an optional experimental toggle or otherwise) so that people can at least get feature parity with optifine users?
yeah I doubt optifine added support for it, as they never do mod compats. I'm unsure exactly what needs to be done, but the lead dev of DH, James, stated that with the release of DH 2.0 it works with optifine and that iris needs to add support for it. I'm sure once we get the two dev teams talking, this issue can be resolved fairly quickly as it seems like DH team knows what the iris team needs to change/add to make it work
I'm kinda curious- how come optifine supports it (apparently?) out of the box but iris doesn't? Or was optifine specifically updated to include support for it like it is now being requested/worked on for iris?
optifine does not support DH. pretty sure its the other way around, where DH edits/patches itself into optifine's shader stuff (idk exactly how. not a programmer)
DH technically does have iris integration (it was available in earlier test builds) but due to the way DH edited iris stability and compatability issues were present (most notably with shaders that use a certain type of rendering) so it was opted to remove that in favour of a proper solution. all the stuff on DH's side is there and waiting for iris to make the changes on its side.
tl:dr. optifine bad; DH has to beat it into submission. iris good; DH just asks it nicely but iris doesn't understand yet so will take some time to update it.
Partial in what way? Meaning the DH chunks still render but not with shaders, or something else?
The next Iris release will have partial compatibility.
Thanks for the info, these are good news indeed.
Some issues with bsl but seems to be mostly working now that oculus has updated from upstream
that's on the shader's side to fix. the main aspect is that DH chunks are able to be drawn with shaders active. there is a modified version of complementary shaders somewhere on the DH discord server that implements a "fix" for the harsh transition by having vanilla chunks fade out with distance
I have this graphical bug with Distant Horizons and Iris Shaders (Sildur's Shaders)
Is there a way to fix it ?
It looks like the stars in the game
edit : disabling "Metallic reflections" in Sildur's Shader settings fix it
Well, Distant Horizons still doesn't work with Sildur's shader..
I've encountered this issue as well with Sildur's shaders and I suspected it was from DH as well. However, I think you must post this to the shader author since I don't think it is something addressable on the DH side.
I don't think there is sufficient support in Iris / Distant Horizons / OptiFine at this time for the shader author to have hopes of doing much to fix the rendering. Essentially this is the result of (from the shader's standpoint) garbage being placed in the shader's first rendering buffer so you'll get all sorts of random chaos depending on the shader. BSL, Complementary, and other shaders that don't use deferred rendering are the main shader packs that have hope of working at all.
Tried blendium as well a while back but it doesn't help when using shaders. I'm also curious if there's something I'm missing like starkgate mentioned, because out of the box it clearly doesn't work.
Sounds very promising. I gave it a try and while I can indeed see the blending of vanilla Minecraft rendering and DH LODs, I cannot see any blending when shaders are enabled. The description mentions the use of a specific shaderpack for Iris, do you know where to find it?
https://github.com/Steveplays28/blendium
👀
Sounds very promising. I gave it a try and while I can indeed see the blending of vanilla Minecraft rendering and DH LODs, I cannot see any blending when shaders are enabled. The description mentions the use of a specific shaderpack for Iris, do you know where to find it?
[...] The description mentions the use of a specific shaderpack for Iris, do you know where to find it?
FYI, asked the author and he gave me this list of compatible shaders: https://gist.github.com/Steveplays28/52db568f297ded527da56dbe6deeec0e