Previously we injected it as a regular builtin resource pack (like the
Programmer Art pack) and hid it on the resource pack screen but this is bad for
several reasons. The most significant one being that it can be re-ordered and
makes the resource pack list ordering weird if you don't know that there is an
invisible pack there.
It also unnecessarily messes with other mods which make certain assumptions
about configurable resource packs (e.g. EBE, though in that case, it merely
triggers an existing bug in EBE).
We now instead inject it into the final resource pack list which gets
constructed from the configured packs, but never as a configurable pack itself.
The `yaw` value of non-client-players is constraint to [0; 360), so when that
boundary is crossed, the `renderYaw` starts interpolating to its goal the
incorrect way round (instead of crossing the 360 boundary as well).
Instead we now use the `headYaw` value, which does not wrap around and as such
does not have this issue.
By simply replacing the private field with a concrete type, so we do not need to
manually register one when constructing the gson instance (which is evidently
too easy to forget about).
No clue why this extra hud hiding was even there in the first place, the
renderer already takes care of properly hiding the hud (without hiding the
nametags) as it does for videos as well.
Either when it is cleared or when it is loaded from the keyframe repository, if
you exit the replay without any further changes, this used to not be saved.
That was never actually finished and we do not need to keep it around anymore.
Whether we add its successor once that is ready for production use remains to be
seen.
Similar to High Quality, it is too unpredictable, sometimes giving bad quality
and sometimes being unbearably slow. We should just encourage everyone to set
their bitrate manually.
Half the reason we swapped the render queue / settings parent relationship was
so we don't need to go through the settings screen to access the queue. But for
some reason I stopped half way through and didn't also move the "You need at
last two keyframes." popup. This commit rectifies that.
Iris derives that one from the frameStartNanos argument passed to the render
method and shaders usually use it to do animations. Prior to this commit we
always pass 0 which effectively froze any shader animations.
With this commit, we now compute the frameStartNanos based on the
FPS of the video we are rendering (so animations will happen in real time when
watching the video) or based on the time in the replay (so animations will
be influenced by playback speed / be frozen if the replay is frozen).
We default to the video time based approach because the replay time one may
produce undesirable results when it comes to things like motion blur and TAA.
In particular, Iris updates its frame counter and timer in the outer method, so
if we only call the inner one, then its shadows and sky will not update
properly.
Since the render method also renders the GUI, we set the current screen to null
and cancel the HUD during rendering. MC also clears the depth before rendering
the HUD, which we don't want because it breaks the depth map export, so we
cancel that as well.
This also allows Vanilla post-processing (aka Super Secret Settings, aka Vanilla
Shaders) as well as entity outlines to function properly cause those are applied
in that method as well.
Should have done this a long time ago but better late than never.
Closes#321
The previous one, blue with no shadow, had horrible contrast with the button
background and did not fit well with any of the other buttons.
Now it does (except that it's not yet in the 20-pixel width/height style).
Since MC provides no reliable way to get the connection while still in the login
phase, Fabric API tries to determine it either from MinecraftClient's connection
field (for the integrated server) or from the ConnectScreen (for multiplayer).
However, neither is present during a replay, leading to the aforementioned
error.
To fix this, we store our ClientConnection in MinecraftClient's connection
field. This should have no significant effect on vanilla behavior.
Also remove the dead Forge 1.14 code which was in the same place.
Creates a dedicated folder for each video and does not depend on ffmpeg, just
like the EXRWriter (but supporting all MC versions).
Also does 32 bit depth export by chunking the 32-bit float into the 8-bit BGRA
component channels.
