Skip to content

Make model don't use too much memory#77

Merged
boubou19 merged 6 commits intoGTNewHorizons:masterfrom
AnsonYeung:model-memory
Apr 22, 2026
Merged

Make model don't use too much memory#77
boubou19 merged 6 commits intoGTNewHorizons:masterfrom
AnsonYeung:model-memory

Conversation

@AnsonYeung
Copy link
Copy Markdown

@AnsonYeung AnsonYeung commented Apr 21, 2026

Improve the model rendering code so it doesn't instantiate 48 models but only 2 models. The rotation of the model is delayed and calculated together with the translation. The lighting calculation is also included.

@AnsonYeung AnsonYeung marked this pull request as draft April 21, 2026 15:35
@AnsonYeung AnsonYeung marked this pull request as ready for review April 21, 2026 18:34
@AnsonYeung
Copy link
Copy Markdown
Author

AnsonYeung commented Apr 22, 2026

Some context for the PR:

The main memory usage is from the 35 gates, each gate have approx 2-4 wire models. For each wire model, there is 48 variants, 2 (flip) * 6 (faces) * 4 (rotation). Each model contain 100-200 Vector3. Each Vector3 contains 3 double which means 24 bytes. A very conservation calculation already gives 35*2*48*100*24=8064000 so 8MB. This very conservative estimate didn't include the redstone torch model and base model included in every gate and that's why the actual number is higher.

This PR reduce the 48 variants to 2 variants, resulting in 24x lower memory usage.

The PR changes the model transformations to be computed on the fly during renderModel. This is a function that eventually calls Tessellator.instance.addVertexWithUV with transformed vertex. From testing this renderModel method is called when any block in the world change or the player hold a redstone gate in the inventory. The extra performance cost by delaying such computation is probably ok, although I don't understand enough about rendering to judge.

The model.render is called with a TransformationList and not just passing the 2 transformation as 2 separate arguments, as there can only be one transformation present in the argument list or else the first transformation will be ignored silently. It is also called with the light model, which will compute after the full transformation (including the translation and uv transformation). The 2 extra transformations does not affect the light computation as the computation only depends on the normal at the vertex, which is unchanged by those 2 transformation.

This PR also won't increase the memory usage of the renderModel method by a lot, since the actual transformation is done vector by vector and won't allocate the full model at once.

@boubou19 boubou19 merged commit a09f1c4 into GTNewHorizons:master Apr 22, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants