Thallium is a mod which claims to improve the game's performance. Not only does it fail to offer any improvement to the game's performance, it misleads and lies to users while severely breaking the game. For the short list of improvements the mod claims to add, only a small handful are even implemented, and even fewer of them actually work. For what's left that actually works, there are generally other mods available which implement the same patches.
Generally speaking, tearing apart and analyzing other people's work is something I don't participate in. However, Thallium has continued to be a thorn in my side due to how it piggybacks off the branding and reputation I have made for my own optimization mods, Phosphor, Lithium, and Sodium.
Not only has the author continued to mislead the community, they have done so while rejecting and censoring any crticism made regarding their projects, and have have acted in a childish, immature manner with no sense of responsibility for their own actions.
The author's primary motive appears to be about pushing traffic for reward programs and affiliate programs linked to these projects. Because these revenue sources are directly connected to how many projects you can publish and how many downloads you can manage through them, there is likely little incentive for the author of these mods to alter their current behavior.
This behavior damages Fabric's trust as a platform for modding and only operates to confuse new users who are not familiar with the ecosystem. While I strongly believe in Fabric's role in providing an inclusive and welcoming space for mod developers, I do not feel that deceiving and lying to users, stealing other people's code, and other parasitic behaviors should be tolerated.
This code is plainly broken. Without disabling the Mixin by hacking into the mod's files, the game will not even boot
because MixinClientChunkMap tries to cancel a constructor with an injection.
@Inject(at = @At("TAIL"), method = "<init>", cancellable = true)
public void init(class_631 c, int loadDistance, CallbackInfo ci) {I don't really understand how this made it into a release. The only way to get Minecraft to launch successfully is through modifying Thallium's mod JAR to disable the patch. As such, any analysis past this point will either be performed through looking at the published source code or through running the mod with this patch disabled.
Moving on... If we examine this patch a bit more, we quickly stumble across another advertised feature on the mod's page called "directional chunk radius".
public boolean inInRadius(int chunkX, int chunkZ) {
...
// Directional Rendering
// Unless in F5 Third person mode, the player can't see all the chunks behind them.
// In vanilla this is not taken into consideration causing excess chunks
// to be "in radius" when they are not in the radius.The comment doesn't quite explain what's going on all that well, but looking at the code, we can see that it overwrites the function used for checking whether a chunk is contained in the client chunk map and adds a check to see whether the chunk is behind the direction the camera is facing.
The ramifications of doing this are quite grave. Because of the way Minecraft stores chunks in a 2-dimensional array (instead of a hash table or similar structure) and how it overwrites old chunks in it as the player traverses the world, this method exists to determine whether a chunk in the array actually matches the requested coordinates, as any chunks in the array which are outside the radius around the player's current position are invalid.
Patching this method like Thallium does means that the chunks which are loosely behind the player will simply not exist, and that attempts to access, load, or unload those chunks will fail. When the game goes to access these chunks, they will instead be treated as empty, uninitialized air chunks, which could result in bugs like entities falling through chunks as the player looks around and all other kinds of bugs.
Not only does this break the game, it makes no sense in the first place. Minecraft already makes use of frustum culling to skip rendering chunks which are outside the camera's field of view, and it's not clear what the mod is trying to do by patching it here.
Thallium claims to optimize animated textures by only ticking those which are visible. At first glance, this seems legitimate, and it is a common optimization that has seen adoption in a number of mods, such as OptiFine, VanillaFix, and even in my own mod, Sodium.
Updating animated textures on the GPU is very slow because each row for every texture has to be uploaded individually. Worse yet, Minecraft updates every animated texture regardless of it actually being visible in the world. When high-resolution textures are used or resources packs/mods add additional animated textures, this quickly becomes a bottleneck on the client.
However, while Thallium claims to "fix" this, it actually just breaks it entirely with a partial implementation which ends up doing nothing more than disabling animated textures. While this may improve frame rates by disabling the slow texture updates, it also disables all animated textures. This is done in such a way where the only conclusion is that the code could've never possibly worked because it's a fundamentally incomplete implementation, making it blatant deception to list it as a feature.
Thallium overwrites the tickAnimatedSprites function in SpriteAtlasTexture, which as the name implies, is
responsible for ticking the animated textures. The replacement code checks over every animated texture in the game and
checks to see if it was marked as needing a texture update, and if so, updates the texture.
However, the markNeedsAnimationUpdate function, which is responsible for marking a texture as needing a texture update,
is never actually called by any code in Thallium (as verified by a quick search using grep "\.markNeedsAnimationUpdate" **/*.java).
As described earlier, if a texture is never marked for updates, then it will never be updated.
In effect, this means that the code to animate textures is overwritten with a function which never actually updates textures because nothing is telling it that the textures are visible, meaning that all animated textures end up disabled when the mod is installed.
While one might be able to brush this off as nothing more than a bug, it seems more likely to be deception (or utter incompetence.) This is because in order to mark a texture as needing an update, you have to firstly know what textures are even visible.
The code for knowing what textures are visible is non-trivial and consists of multiple steps. As a rough outline, you need to be able to a) find which chunks are visible, b) track all the animated textures used by blocks in a rendered chunk, and c) be able to store that information for every chunk in the world. Thallium makes no attempt to do any of this, and includes nothing which touches chunk rendering code. It's as if the code is only for show.
If these critical files were simply missing, the mixin configuration file in the mod (which lists every file that is patched) would detect the missing files and crash the game. The only explanation is that the code simply never existed in the first place, either because the feature was left incomplete unknowingly (which would assume it was never tested, since again, this breaks all animations in an incredibly obvious manner) or that the mod author knew it was incomplete and decided to list it as a feature anyways, amounting to nothing more than the author lying to users.
For an example of how another mod might implement this, one can take a look at VanillaFix's implementation. Interestingly, the names used in Thallium's incomplete patches are identical to those in VanillaFix.
Thallium claims to "[optimize] entity large collisions". This is described a bit vaguely (and sometimes reduced to just "optimized entity collisions"), which would make it sound like the mod optimizes entity collisions in a general sense.
The project's page actually provides a before/after comparison of the game server's tick time graph, though without any other information to go with it. It seems to suggest that these optimizations are for situations with huge amounts of entity cramming, such as in animal pens.
Thankfully, the sources are available, so we can figure out what it's doing by reading them instead.
/**
* @author Based on the idea of Paper patch 137, but done completely different.
* @reason Cap Entity collisions
*
* Limit a single entity to colliding a max of configurable times per tick.
* This will alleviate issues where living entities are hoarded in 1x1 pens
*/
In other words, Thallium simply disables the entity-against-entity collision check if a given entity has collided with more than 8 entities in the last 40 ticks (2 seconds), in effect making it so entities in a tight pen do not perform collision checks against one another.
The author mentions that the patch is based upon the same idea as Paper's patch for capping entity collisions, but it actually works in a different manner entirely. While Paper's patch limits the number of entities something can collide with simulatenously in one calculation, Thallium's patch changes it so entities can simply no-clip through all other entities after a small number of collisions.
The difference between these things is quite substantial, and means that they are not directly comparable. Whether or not Thallium's patch here is a good idea is up for debate, but it's not "optimization" -- it's just disabling things. Though, that doesn't stop the mod's author from claiming that their patch is "even better" than Paper's.
Another severe issue that occurs when using Thallium is that the player is violently thrown into the ground when stepping off blocks.
I didn't actually reverse engineer the full extent of what is going wrong here, but it looks to be a result of Thallium randomly patching methods in entity logic without any understanding of the code.
This patch works by replacing the sin and cos functions the game uses between world generation, mob AI, etc, with a "optimized" variant that sacrifices precision for a smaller lookup table or faster implementation. This means that the results returned from it will not be the same as vanilla, causing small changes in these areas of the game.
It is known that OptiFine's analogue of this feature (called "Fast Math") alters world generation, and there is no reason why Thallium's implementation would be different in this respect.
The functions appear to be copied verbatim from the java-gaming forum, which is sort of the go-to reference for mods which implement "fast math" it seems.
Thallium has been known to use code from other mods in violation of their open-source licenses. Notably, Thallium copied code from Sodium and failed to both attribute the original source and provide their own mod's sources alongside it, as required by the license.
Almost immediately after the issue was opened, the author closed the GitHub project. Some time later, the project was re-opened with comments from other users deleted.
The infringing sources have since been deleted, but their prior existence be found in the deletion commit here. The author titles the commit which removes the infringing sources with:
Sodium thinks they own every fastutil implementation. Go bug Mojang to DMCA Glowstone then.
And, later on, includes in the source code:
Removed because Sodium thinks they hold copyright for every fastutil implementation of chunkmanagers TODO report to fastutil
In the past, Thallium skipped world rendering as an "optimization". Due to how Minecraft/OpenGL rendering works, the contents of the screen must be "cleared" before rendering, otherwise the next frame's contents will overlap the previous one (producing a strange visual effect that was commonly seen when no-clipping through the world in older games.)
However, because the screen's contents must be explicitly cleared, this means that not doing so simply results in the previous frame being displayed again if nothing else in rendered. By skipping the step of rendering a frame but still asking the graphics card to present it, both the game and third-party software will believe it is achieving a higher frame rate than in actuality because it is displaying the same frame multiple times.
This is, again, plain and simple deception. When the mod was criticized for doing this, the GitHub and CurseForge comments section were closed. Later on, the author removed the code after claiming it was "unused".
If we look back at Thallium's full feature list (as provided on the project's page) and the issues/deception described above, it becomes clear that the mod isn't doing much of value either way. More accurately, the full feature list could be written as:
"Replaces the default chunk manager to use fast lookup maps"(Breaks chunk management by misunderstanding the code in other mods)"Optimizes(Disables) animated texturesto tick those only in loaded chunks"(look at Sodium for a functional implementation)- "Optimizes BlockPos methods" (micro-optimization that uses trivial inlining)
- "Uses Fast Math, Optimized sine & cosine" (for tiny improvements in performance, changes world generation and game math)
"Adds directional chunk radius"(making "non-visible" chunks disappear from the client)- "Optimized entity large collisions" (by disabling entity collisions entirely when too many happen, look at Lithium for entity collision/cramming optimizations without compromise)
- "Optimized Biped Entity Model"
- "Fog Disable Option" (unlikely to impact performance any, also offered by NoFog)
If you are looking for other optimization mods that actually help performance, consider taking a look at the community's go-to list of optimization mods for Fabric.
Well about 20 other people have said otherwise, so idk who to believe anymore...