Minecraftforge: [Suggestion] Moving large parts of the content pipeline to compile time where possible.

[FaeyUmbrea]

I'm a game developer and don't have much experience with how you built the Mod-Loader and with how minecraft is built internally, I'll just frontload this information here so you know my assumptions are going to be made on the basis of the state of the art in game development and not based on how the game is actually programmed.

So to me, some of the steps done in the loading process, as advertised by the loading screen, in forge seem a bit unnecessary to do at the games load time rather than the individual mods compile time. For instance model baking. Since each mod has to be recompiled for new minecraft versions anyhow due to non-compatible changes in the API (at least thats what most devs say) and the implementation of the core files in minecraft only changing during such an update, it would seem to me that moving the whole baking process from game-load to the mod compilation toolchain would remove a largely redundant process from each launch of the game.

Next, I get that the process of texture stitiching will not be that easily frontloaded compared to model baking, since thats generally a more complex process when you can't control the models beforehand. But I propose that you could theoretically cache all the textures and instantly load the cached files from the harddrive when the mods didn't change. At least having a checksum over the entire content of the mod-folder would prevent duplicate pre-processing in the event none of the files ever changed. Reducing loadtimes tremendously for larger modpacks with slower updates.

In the event this was already suggested and rejected, I'd first invite you kindly to reconsider and I'd enjoy to hear your reasoning as to why not to implement these changes, if you reject them again.

[Barteks2x]

Note: I'm probably not really qualified to fully answer this here as I don't normally deal with rendering/models in forge (or anything in forge actually, I only made a few small PRs).

I thought about such idea too, and at first I didn't really see any big reason why it wouldn't work, and it might allow to make loading models a bit faster. But it would definitely be huge change from vanilla.

But there are some reasons why I think it may not work that well:

• Adding new features to forge models could become much harder, as any changes would have to keep compatibility with the old (most likely binary) format. Even some optimizations in minor forge versions may become impossible without rebuilding all model files.
• Either resourcepacks that change models would have to support the binary format, or forge would also have to keep the code for loading normal models. It also means resource pack authors can't easily take the mod's models and edit them in their text editor.
• Mods may have custom baked model classes. And there are many mods using them. Either they would have to find a way to serialize and deserialize their models, and also have it done at compile time, or their models would have to be baked at runtime anyway. That could make the time savings unnoticable for bigger modpacks if a lot of mods do that. Especially when model baking doesn't seem to be that big portion of the loading time. But I may be wrong here.
• If that process is actually done at compile time and not by whoever is making the models, using a special tool, then development environment would need to be excluded. It would also add yet another difference everyone would need to be aware of in development environment. And again, because of that, json models would still have to be supported.

As for texture stitching - the textures have to be restitched every time a resource pack is loaded. So forge would also have to keep track of resource packs. And I could also imagine some config options influencing which textures end up in the texture atlas.

Essentially, i think it would be a lot of work to do, for small benefit, and could make it harder to introduce new features.

[williewillus]

To echo what was said above, the reason all this happens on startup is because resource packs can replace any of it.

And RP makers don't necessarily know or want to be dependent on forge's binary format.

What could be done is per-instance caching, where the models are dumped to disk after first startup, and this cache is invalidated every time a mod or RP is changed, but that has a lot of potentially nasty details

[FaeyUmbrea]

Okay, I'll admit I didn't fully think about resource packs since I rarely use those and second the oppinion about that and I guess that would make it a whole deal more complex.

I'd still like some information on what the process called texture stitching actually means in the context of forge, since it seems to be very different from what I'm used to.

[diesieben07]

Texture stitching in Minecraft (Forge does not really change the concept of it) means taking all the individual block and item textures and stitching them together into one giant texture, so that blocks and items in game can be rendered efficiently. If they were all loaded as individual textures, the GPU would have to constantly swap textures, to the point where the game would probably not run properly at all.

[FaeyUmbrea]

Wait so is that 1 whole texture for everything or one for items and one for blocks?

[FaeyUmbrea]

Also I've been brainstorming why Minecraft gets so incredibly inefficient when using mods. How exactly does the renderer work? Do you upload the atlas texture every frame?

[williewillus]

1 whole texture for all items and blocks, other things generally use their own textures

and this starting to become a "hop on forums/irc/discord and discuss" thread, the issue tracker should be for focused discussion.

there's many many ways MC gets inefficient with mods. I'd say the phrase that describes it most aptly though is "death by 1000 cuts"

see: http://www.minecraftforge.net/forum/, #minecraftforge on irc.esper.net, and https://discord.gg/moddedmc

[FaeyUmbrea]

Alright, back to the suggestion up there, I'd still think that every bit of optimising would be a good idea, there is really no point in waiting on any process any longer than necessary.

[LexManos]

Honestly this isn't the place for this discussion, you should go to the forums, do a bit of research so you know atleast he basics of what you're talking about.
Minecraft is not a normal game. We dont get to work with binary/optimized data much. There isn't MUCH we can optimize. Ya long startup times can get tiresome, but it's just something you got to deal with.
And honestly, testing out a few of the latest major modpacks, bulk of the startup time isn't spent in Forge/MC code but in Mod code. So there is that.