-
-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a ConfigureMainRenderTargetEvent for enabling stenciling #1715
base: 1.21.x
Are you sure you want to change the base?
Create a ConfigureMainRenderTargetEvent for enabling stenciling #1715
Conversation
Last commit published: b6c5afb4f75acb87ba2c3281b71533d21de2f53f. PR PublishingThe artifacts published by this PR:
Repository DeclarationIn order to use the artifacts published by the PR, add the following repository to your buildscript: repositories {
maven {
name 'Maven for PR #1715' // https://github.com/neoforged/NeoForge/pull/1715
url 'https://prmaven.neoforged.net/NeoForge/pr1715'
content {
includeModule('net.neoforged', 'testframework')
includeModule('net.neoforged', 'neoforge')
}
}
} MDK installationIn order to setup a MDK using the latest PR version, run the following commands in a terminal. mkdir NeoForge-pr1715
cd NeoForge-pr1715
curl -L https://prmaven.neoforged.net/NeoForge/pr1715/net/neoforged/neoforge/21.4.21-beta-pr-1715-feature-depth-stenciling/mdk-pr1715.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip To test a production environment, you can download the installer from here. |
RenderTargetDescriptor rendertargetdescriptor = switch (entry.getValue()) { | ||
case PostChainConfig.FixedSizedTarget(int i, int j) -> { | ||
- yield new RenderTargetDescriptor(i, j, true); | ||
+ yield new RenderTargetDescriptor(i, j, useDepth, useStencil); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since vanilla always enables depth should we do the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since shaders targeting vanilla only work on the main render target, which has depth enabled, this should effectively be the same - It should only be different if somebody tries to set up a render target with depth disabled which I feel is unlikely to happen anyway
e354ca3
to
f85ba22
Compare
* This event is fired on the mod-speciffic event bus, only on the {@linkplain LogicalSide#CLIENT logical client}. | ||
*/ | ||
public class ConfigureMainRenderTargetEvent extends Event implements IModBusEvent { | ||
private boolean useDepth; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd remove this if it cannot be set to false (and why would it be possible to do so)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why I kept it is because vanilla doesn't exactly use the depth buffer themselves*, so they may change it to false in The Future:tm: for VRAM purposes. Furthermore, it allows mods to be explicit about whether they need the depth information to be written. (I see as this a good thing)
The defaults are basically lifted from vanilla code currently, though it may be better to inline them where the event is actually constructed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd not keep this "in reserve" in the API. If Vanilla does add it, we can re-add it then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This functionality should be removed for now. We can re-assess if Mojang changes something or there is a formal feature request to allow it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of removing it completely, I instead changed the patch to pass this boolean, as well as the desired width and height to the event. As we always pass true
, I made it final and removed the set/enable method.
+ | ||
+ if (!useDepth && useStencil) { | ||
+ var capabilities = org.lwjgl.opengl.GL.getCapabilities(); | ||
+ if (!capabilities.GL_ARB_texture_stencil8 && !capabilities.OpenGL44) { | ||
+ throw new UnsupportedOperationException("Stencil-only buffers require GL_ARB_texture_stencil8 OR OpenGL 4.4"); | ||
+ } | ||
+ } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a use-case for this or is this going to be effectively dead code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OpenGL technically supports it, and it's a supported combination of parameters, so rather than getting a confusing error about framebuffer completeness with no exception, I'd rather throw an exception beforehand.
You are correct though, in that the average user would probably not hit this branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is perf-critical code I would suggest dropping this check. Presumably the modder raising the incorrect flag combo would see a breakage elsewhere.
If not, we can keep it for informative purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not performance critical, as it's only checked on construct. As far as I'm aware, vanilla prefers to reuse render targets rather than re-create them every frame.
@FiniteReality, this pull request has conflicts, please resolve them for this PR to move forward. |
b6c15f2
to
5537e4c
Compare
5537e4c
to
b7d4e14
Compare
…nTarget configuration event
b8e0333
to
ef3f2f4
Compare
@OnlyIn(Dist.CLIENT) | ||
- public static record TargetInput(String samplerName, ResourceLocation targetId, boolean depthBuffer, boolean bilinear) implements PostPass.Input { | ||
+ public static record TargetInput(String samplerName, ResourceLocation targetId, BufferType bufferType, boolean bilinear) implements PostPass.Input { | ||
+ public enum BufferType { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: should this be @OnlyIn
too, or should we move it to another type? This was the suggestion by @embeddedt to combine the separate bools into a single enum
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the overall strategy is sound, but I would remove all of the patches to make depth disable-able. That will already reduce the amount of patching by quite a bit. I would try to reduce the patch size even further. Finally, might be nice to reactivate StencilEnableTest
to at least validate that enabling the stencil buffer won't cause everything to blow up.
} | ||
+ | ||
+ @Nullable | ||
+ public abstract ResourceDescriptor<T> getDescriptor(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method needs to not be abstract and instead return null by default.
+ useDepth |= renderDescriptor.useDepth(); | ||
+ useStencil |= renderDescriptor.useStencil(); | ||
+ } else { | ||
+ useDepth |= p_361871_.get(resourcelocation).get().useDepth; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason to look this up three times instead of once?
@FiniteReality, this pull request has conflicts, please resolve them for this PR to move forward. |
This needed a small change to mod loading: it has been separated into two separate methods instead of the one
ClientModLoader.begin
to enable configuring the render target.The API I've implemented here is somewhat a placeholder, but ideally we would be able to add additional methods for things like additional color attachments, or potentially listeners for when the render target gets resized.