feat(csg): -texchart, what each texture costs the bsp - #2
Merged
Merged
Conversation
On a map compiled with -nowadtextures the texture lump is most of the file: measured 82.8% of zm_azteca and 69.9% of zm_eichen, against 8.7% and 15.4% for lighting. -chart reports a single texdata total and stops there, which is where the question actually starts. The report lists textures by bytes, flags any whose pixels are byte for byte identical, and crosses each against the surface area it paints. The texture axes carry the texels-per-unit scale, so the number of pixels a texture ever displays is computable rather than a guess: with 4x more pixels than it displays, a texture can lose half its resolution in each axis and still have a pixel per pixel on screen. That distinction is the point. A naive "halve everything 256px and up" projection claimed 70% off zm_azteca; the real answer there is that nothing is oversampled, because those textures tile across very large surfaces and downscaling would just look worse. zm_eichen has 3 textures worth halving (6.1%) and one duplicated pair. Off by default. Only reads back the lump CSG has already written, so it cannot affect the output.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Measured both of the maps in
Documents/Mapping, compiled with their real flags:Textures are the map.
-chartprints onetexdatatotal and stops, so there is no way to tell which textures that is or whether the resolution is doing any work.This also kills two ideas that looked reasonable before measuring: lightmap deduplication targets 9-15% of the file and would recover a fraction of that, and duplicate textures are essentially absent (0.1% on eichen, 0 on azteca). Neither is worth building.
What it does
-texchart, off by default, afterWriteMiptex:WriteFacefor hull 0 only.Why the area cross-reference matters
A naive "halve every texture 256px and up" projection claimed 70% off zm_azteca. With the area accounted for, the real answer is that nothing on azteca is oversampled — those textures tile across very large surfaces, and downscaling would only look worse. The naive number was measuring nothing.
Actual results:
zm_azteca: 32 textures, 2.269.304 B, nothing carrying 4x more pixels than it displays.zm_eichen: 90 textures, 1.941.720 B, 3 worth halving (118.326 B, 6.1%), one duplicated pair (black/white, 32x32, 2.172 B).The duplicate figure cross-checks against an independent Python parse of the same bsp.
Safety
Off by default, and
AccumulateTextureAreareturns immediately when it is off. It only reads back the lump CSG has already written, so it cannot change compiler output. All five tools build clean; with the flag absent CSG prints nothing extra.