mojira.dev
MC-11595

1.5 HD Texture pack stitched images greater than 2048 resolution result in massive performance drop.

I am currently in the process of converting a personal texture pack to 1.5 when I noticed massive performance drops after using the texture pack conversion tool by dinnerbone in comparison to 1.4.7 frames.

Upon investigation, after using default animations, taking out and slowly putting textures back in while looking at the Stitched textures PNG files I noticed that once the block stitched textures goes above 2048x2048 resolution to 4096x2048 the game goes from a solid 90+ frames per second to 2 or 3.

I have included both stitched images. The only difference between the two is that I have removed the mycel_top.png and as a result the image size has been increased from 2048x2048 to 4096x2048.

If needed, I can also include zipped versions of the texture pack, just wasn't sure of the best method to test this.

Related issues

Attachments

Comments

migrated
[media][media][media][media][media][media][media][media]
Mace Madunusus

Added two in-game screenshots of FPS. The only difference is adding the mycel_top image which changes the stitched terrain from 2048x2048 to 4096x2048. The FPS is currently limited by Dxtory to 30 because it likes to keep resetting that limit on me. However, the performance decrease is still large.

Mace Madunusus

Added zips of partial texture packs for testing.

Erik Broes

Unable to reproduce, with or without it i get identical performance.

Mace Madunusus

Hmm, that's weird. Think it could be related to Java 7 update 7? Since java is at update 17 or so right now.

I also had two others test this with me as well. Their performance drops were as follows: 200 > 80... and 90>45. While theirs were still playable, they noticed those big drops as well. I'll ask them later to see what version of Java they could be on.

Edit: Just tested on the official 1.5 release as this was on the pre-release. Same result on my PC. I'll try updating Java next. Also tried turning off smooth lighting as I saw that some people noticed low FPS as a result, but no change in performance there.

Mace Madunusus

Just updated Geforce GFX drivers to the latest 314.09 release and updated Java to update 17 64-bit and still had the same performance drop switching between the two.

Edit: Just tried two completely different texture packs that were not my own. Switching between their different resolutions gave the same large performance drop while playing the same in 1.4.7 versions would result in normal FPS.

Edit 2: Seemed my MC was still on the pre-release when I told it to update. It seems to be fixed in the official 1.5 release. Feel free to close this!

Ryan S

I can confirm this issue. Running fresh Windows 7 install, fully updated drivers, and fully updated Java. I loaded a fresh copy of MC and Sphax 128 together and when I run this texture pack I get less than 10fps. Typically I run MC at around 120fps. I can also confirm this is not an issue with my OS or any software or driver files as it ran the same before I reinstalled my OS. In fact, one reason I reinstalled everything was because I thought something in my system was corrupt. Running 1st generation i7 with Radeon HD5770.

Ryan S

These screenshots show that the issue is current in the 1.5.1 pre-release.

Maarten Thijs

isn't this related to your computer not being able to render this quality? most other games give you a graphic option like: low-normal-fantastic. maybe your pc can't handle "fantastic" graphics(texturepacks)

Mace Madunusus

It shouldn't in this game. Theoretically most computers should be able to handle up to 1024x texture packs for a game like this without any issue at all. For example, my PC can do texture settings for Battlefield 3 on High without any FPS drops, and its 6-7 years old now. That uses almost 1GB of video memory, while MC shouldn't go above 400mb of video memory, hell, I'd even be inclined to say 200mb or 100mb, but I don't know how everything in MC is stored.

Usually in games, texture settings have minimal impact on performance so long as you have a decent amount of video memory. The only reason I cannot go to ultra on BF3 for textures is that you need 1.5gb of video memory and I only have 1.

There is something Mojang could do for textures, but it wouldn't make the game run much higher as it only increases loading times. Though, what I am about to say is more related related to engines like UDK, Cryengine, and Quake 3 Engine (ID Tech 3) and may not fully apply here as there is hardly the same amount of textures to be loaded. That is converting the PNG images to TGA. I have found, as well as other developers, that PNG reduces load times because it has to decompress the image twice, vs once. This is because the PNG is packaged usually inside a compressed file like a JAR or ZIP. It has to decompress one before decompressing the PNG for rendering. With TGA it only has to do the zip/jar decompression and with a TGA being in a compressed package, it compresses itself very well, almost to the point of a PNG. In terms of loading efficiency: TGA>JPG>PNG. In terms of quality: TGA>PNG>JPG at least in my tests. The only problem with TGA is that it does not automatically create an alpha channel. Though that can be considered as a good thing, as people are less likely to steal content from other texture packs as it requires a little bit of effort to create that alpha channel.

Idk, enough rambling. 😛

C.J. Wijtmans

uhm do you have evidence of mc only taking up 400 mb of video memory with 2k textures? seems most unlikely. note RAM is not video memory...

Mace Madunusus

Its more or less logical, most of the texture data for MC is miniscule in comparison to other games. I've designed multiple scenes in the engines that I mentioned, with way more high res textures with normals, specular, etc maps as well on top of that and I didn't get more than 500mb on the vram on an entire 40,000 unit x 40,000 unit level. I haven't done any specific tests on MC, but this is based on previous game experience.

There also shouldn't be a lot of overlay in the buffers because well they're solid box objects and there isnt a lot of transparency, especially with the fact that MC uses voxels and not polygons. So that shouldn't be taking up a ton of video memory either. I don't know about the chunk format, and that could be partially saved in video memory as well as ram, but the data within them for a normal view distance still shouldn't cause the whole thing to surpass 400mb of video memory.

And yes, I do know the difference between video memory and RAM. I wouldn't even be able to run BF3 on 1gb of ram as that is what I said I only have, but I was talking about video memory instead.

In the end though, if it does take more than 400mb of the vram (we already know MC can be a ram hog, but vram is a different story) that Mojang has some optimizations to do because it really shouldn't even get that high.

C.J. Wijtmans

Most games have optimizations that reduce render times/memory which is not possible in minecraft.. do you have any tool to check vram while running minecraft?

Mace Madunusus

Why wouldn't it be possible? MC only runs on a single core, and mods like optifine have shown it can at the very least do chunk loading multi-core and improving overall performance and quality at the same time. Things like Spigot and Spout have shown that current chunk formats are inefficient and are often prone to memory leaks. In-game MC usually says its only using 300 or so MB out of 1gb using F3 yet checking task manager it is clearly using a lot more. So its largely things Mojang has to do because Java is capable of it.

I don't currently have a tool to check vram as I usually used in-game profiling.

Mace Madunusus

This has returned for me in 1.5.1 on my GTX 280.

I also tested this on 3 other graphics cards including my new one. These cards are an 8800GTS 640mb, GTX 550 TI, GTX 660 2gb all of which have the same result.

ReduxMC

I have the same on my i-5 with 4gb.

kbk

I have a GTX280 yet I can't reproduce this on 1.5.2pre. Is this still a concern?

Mace Madunusus

1.5.2pre has this note in the changelog: Improvements to FPS when using high-resolution texture packs. So it is a possibility it is not a concern, but I have not tested it myself.

Apocalypsing

The problem still persists in 1.5.2. In 1.5.1 and 1.5 I was getting said performance issues with 64x64 textues and higher. In 1.5.2, performance issues aren't noticable with the same 64x64 texture pack (Defscape), but higher-resolution texture packs (128x128+) still have performance issues. There is also a pretty severe memory leak which occurs when switching/loading texture packs.

However, not all hope is lost. In the 13w18 snapshots, the performance issues have disappeared, and so has the memory leak. I did some testing using 128x128, 256x256, and 512x packs. I was able to run the 512x512 texture pack with only 1GB of RAM allocated to Minecraft, which is amazing to see. So the issue appears to be fixed for the future 1.6 release. One of the things listed in that snapshot's changelog was a "new texture loading system", and I'm guessing that Mojang rewrote the texture rendering portion of Minecraft's game engine, to better adapt to the new texture formatting added in 1.5.

If anyone is curious, I was testing on a Core i5 3570K and a HD 7870. Frame rate was always above 100 FPS with all settings maxed out, even with the 512x512 pack I tested, which was just over 200MB in size.

Erik Broes

As noted this will be properly fixed for 1.6.

For 1.5.x there will be no further changes beyond what has been done between 1.5.1 and 1.5.2 (a quick change to make the performance more acceptable).

For 1.6 I did a huge overhaul (from 13w18c and up) of the whole texture system. When you use a highres pack you might still get slowdowns but that will be more of a hardware related issue than anything else.

Mace Madunusus

Erik Broes

Unconfirmed

performance, resource-pack, texture

Snapshot 13w10b, Minecraft 1.5, Minecraft 1.5.1

Snapshot 13w18c

Retrieved