-
-
Notifications
You must be signed in to change notification settings - Fork 193
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
Implement BEFORE stages for extra control #1857
base: 1.21.x
Are you sure you want to change the base?
Implement BEFORE stages for extra control #1857
Conversation
Last commit published: 9a9a4985fd22285b0c011151d6d21ad3977ffc66. 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 #1857' // https://github.com/neoforged/NeoForge/pull/1857
url 'https://prmaven.neoforged.net/NeoForge/pr1857'
content {
includeModule('net.neoforged', 'neoforge')
includeModule('net.neoforged', 'testframework')
}
}
} MDK installationIn order to setup a MDK using the latest PR version, run the following commands in a terminal. mkdir NeoForge-pr1857
cd NeoForge-pr1857
curl -L https://prmaven.neoforged.net/NeoForge/pr1857/net/neoforged/neoforge/21.4.60-beta-pr-1857-feature-additional-render-stages/mdk-pr1857.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. |
Have you tried using the |
The issue is that when you're rendering e.g. fluids in a tank, you only have access to the render type, rather than the relevant stage to draw geometry in. Part of the change here is to make both the before/after stages attached to the render type where relevant. |
Is the problem that |
@FiniteReality, this pull request has conflicts, please resolve them for this PR to move forward. |
This is a relatively naive modification to the existing RenderLevelStageEvent system to implement an additional set of BEFORE stages. The goal is to give more control over geometry rendering at a per-rendertype level. For example, currently, it is rather difficult to render translucent non-chunk based geometry (e.g. the contents of a multi-block tank which spans multiple chunks) as the current events are fired after the game has already rendered to the appropriate buffers, breaking depth sorting and blending.
Admittedly, it is likely that this would then introduce the reverse issue: geometry rendered by a mod will interfere with vanilla geometry (hence my opening of this PR as a draft) but providing these hooks should in theory provide for more control while fitting into the constraints of the existing system.
I think that going forward we need to completely redesign this interface, instead giving modders access to the FrameGraphBuilder in order to configure their own render passes. However, this will need a lot more thought as the frame graph is intended to be a DAG where resources are only written once.