Question about track-count and size of the game

[rubberduck]

Is there a limit of maximal tracks you want to have in sr (because of the game-size)

and how much percent do all tracks take compared to the whole game, are there things that take much space on the disk?

[CryHam]

Good question.
As of now the sizes, all in MiB (I'm putting 7z packed size in (), Lzma is used in installer, and Linux binaries) are:
- tracks:
- 137 our SR tracks: 292 (234) - not that big, rest sums up to more actually
- 8 VDrift tracks: 98 (59) - huge, may delete few
- 19 cars: 59 (40) - quite small

- trees, grasses: 85 (79)
- terrain, road, skies: 101 (100) - weird, it's more than trees. still, it has to be, I'd even expect better terrain textures to take more space.
- objects: 29 (21) - absolutely nothing to be worried, even if reaches 100 (ofc with the usual requirements)
- sounds, gui, hud, and all other stuff: 22 (17) - nothing to mention
- track's ghosts 13 (8) - yes, really low

- all this sums up to 700 (558) MB, and is the size of installer/release

I think tracks are (and were) the biggest size.
But the rest also sums up close (cars, terran textures, vegetation), IMO this is totally OK (makes the game higher quality).
I'm not yet concerned, but soon I'll have to do something.
Probably either when we reach 200 tracks or 1 GB installer, or maybe sooner.

I see only 3 possibilities:
1. content manager (very big thing to code and need a lot of time) issue here
I won't do it (have lot of other things to code), and it is also a questionable thing, will it cover terrain textures and all or only tracks/cars.
And heh yeah, we won't have a server for it, so let's forget this.
2. make 2 packages 1 full, and 1 smaller
I'll probably do it if many people want that or we go over 1GB. This will cause confusion in whole data (need to mark what is necessary in small package). But right now, looking at sum of all the other data than tracks, I don't see the smaller package being much smaller (like half maybe ?)
3. reduction, deleting some of low quality tracks (or very old, or too short and boring etc), leaving only highest quality and best rated ones (but I don't see more than 10 of such tracks now)

Ofc, anyone feel free to comment which way you like or if you have another idea.
I guess 3 will happen naturally, 1 is too big to do, and 2 IDK.

[rubberduck]

are there possibilities to reduce the size of a track (not only how to reduce one track, also something like data of a track is saved in general)

and what does take most space in a track, are there many differences between different tracks?

i have an idea how you could reduce the size of materials

1: use jpg files for preview, they don't have tranperency

2 it should be possible to use jpg files for the rest too, using specularmaps would replace transparency.
(there should be a file like you have for objects and road-materials)

how much work would that be and how much space could you remove?

[CryHam]

Track's heightmap is mostly the biggest and is always unique.
It is saved as 32bit floats. It could be saved as 16bit integer, with saving also max and min value. This would reduce size to half (I think so, didn't try yet).
But this would mean quality loss, and if anybody wanted to edit heightmap (he should use the 32bit float original to not loose it every edit/version (if min,max changes then even more often)).
And because of this I really dislike the idea. Sure, final version of tracks could use this, and repo could have 32bit anyway, right ? Would just make copying a track and making packages/release difficult. And introduce confusion.

There are also few png maps, for: roadDensity, grassDensity, and waterDepth. Aren't big.
Also road.png, terrain.jpg, view.jpg for minimap and preview (jpg's are small).
Still, I think track's size is really small. And were invented so, to be small, since start.

There is a big difference between heightmap sizes. 256 is 256kB, 512 is 1MB, 1024 is 4MB, (2048 would be 16MB and may never be used because of that).
Sure, we could make something smart, like having few global terrain noise maps to choose, (or even generate them with noise params), then use those for the detailed rest of heightmap (eg. 1024 or even 2048), while the base heightmap would be smaller eg. 512 and only this saved in track.

[CryHam]

Hmm. There is a requirement for max texture count (samplers) use. IDK, 16 ? Need to check.
And that is already used in terrain. Not sure.
That's why specular is in diffuse texture's alpha channel, and parallax height in normal's alpha.
This way there are 2 RGBA textures used. Surely I'd like to have specular and height in other texture (would be even much convenient to edit this crap) but then it'd be 3 textures and would make less layers possible and also terrain blending more gpu time consuming.
But yeah, saving them in jpg would reduce the size quite a lot I think.

[Tapio]

Track's heightmap is mostly the biggest and is always unique.
It is saved as 32bit floats. It could be saved as 16bit integer, with saving also max and min value. This would reduce size to half (I think so, didn't try yet).
But this would mean quality loss, and if anybody wanted to edit heightmap (he should use the 32bit float original to not loose it every edit/version (if min,max changes then even more often)).
And because of this I really dislike the idea. Sure, final version of tracks could use this, and repo could have 32bit anyway, right ? Would just make copying a track and making packages/release difficult. And introduce confusion.

16 bit integer gives us 2^16 = 65536 values. If the track has 1 km height differences, that would give 1000m / 65536 = 0.015m = 1.5cm resolution which I imagine is acceptable. However, I don't think any of our current tracks have that high heightmaps. I imagine most fit well under 100m. In that height range, 16 bits gives 1.5mm resolution. I'm having a hard time believing there is any noticeable quality loss, especially given the horizontal terrain grid is nowhere near as granular.

[CryHam]

Yeah I know. Still there are some with 300m others with 100 etc, have to get it first (then what if it changes).
Then comes the other, more important, reason having 2 heightmaps, and the need to edit always float 32bit (and remove it for packages).
Currently heightmaps are 229 MB (7z: 170 MB, they have always the same size so they pack good).
Even if we half that, this is still just 85 MB less from release size (IMO not worth the trouble and complicating all that).

[charlie]

I think in the future you want to have a track manager that downloads tracks (a bit like the STK add on manager).