Procedural cubemaps?

[evertvorster]

Hey there. I know it's been a long time, but this is something that still bothers me. On higher resolution monitors, the backgrounds are quite pixellated. Also, the cube maps form a significant part of the download of the assets.

Would it not make sense to procedurally produce the cubemaps? This website produces them in a browser, so it can't be that CPU intensive: https://tools.wwwtyro.net/space-3d/index.htm

From what it looks like, if you give the program the same seeds, it produces the same cube map, so there would be no need to save them, only the seed. This is something that can be saved in the save file too...

[stephengtuggy]

Yes, it's a great idea. Good to know also that only the seed would need to be saved in the save file.

[BenjamenMeyer]

interesting... @Loki1950 thoughts since you're more aware of the assets stuff than most, especially regarding the VS history

[evertvorster]

There is definitely a trade-off. We will lose the ray-traced starfields that contributed a lot to the eye candy of the early VS. Unfortunately, when you ray trace them at a high enough resolution to look good on high resolution monitors, they are gigantic. That is, if you manage to get the ray tracer working. I only managed to get a few of the star fields ray-traced at higher resolutions.

There are at least three examples of procedural rendering of star fields and nebulae with a specific seed online. As another example, Oolite also procedurally generates the star fields. Unfortunately I know nothing about writing OpenGL code, so I don't even know how big of a task it is to implement a star field renderer.

[Loki1950]

We would need to experiment to see if there is an optimal setting for our purpose ie: no pixelation ,fast generation,light memory footprint. I do like the concept of procedural backgrounds but as evert has said the final maps are huge so just saving the seed would be great but will that be ok to generate on the fly or pregenerate and save it comes down to being a performance issue.

[evertvorster]

The generation part in the browser is pretty quick, so I am assuming that the starfield can be generated every time it is needed. Or, maybe a little before... I know that quite a few of the similar type games play some sort of video that shows the time in hyperspace between star systems while the new star field is being generated. Then the generated starfield does not need to hit the disk at all, and only the seed is saved in the savegame.

Conceivably, the first time the player visits a system, it gets a random seed, which is then saved for further re-use.

What is interesting to note as well, at least on the web-based generation, is that you can pick nebulae on or off, so if a groups of systems are supposed to be in a nebula, all the systems in that area would then have nebula on. Also, and this is just a hunch, there may be a seed for the starfield, and a seed for the nebula, so you can have the same nebula and a different star fields, if you move between systems that are close together.

There may also be an option to pick color of the nebula separately from the shape of the nebula. In this manner, a group of systems in the same nebula can have a consistent color of the nebula, but the shape changes for each system.

So, three seeds may need to be saved. A seed for the star field, a seed for the color of the nebula, and a seed for the shape of the nebula. With this there will be a nice cohesive visuals to the universe, and a very nice uptick in eye candy for VS.

All this would depend on the implementation. Which brings us to the question, who has the skill and inclination to whip up a star field generator for VS in OpenGL?

Last point to mention, this will probably be a non-backwards compatible change to the save files. You can probably use a save file with no seed saved, and generate them on the fly as you travel back to places you have been before, but that seed saved in the save file would probably confuse earlier versions of the engine.

Also, this may break compatibility with Privateer, unless we have the code check for existing cube maps, and load them, otherwise start generating the star maps procedurally.

[evertvorster]

Oh, just in case I have not shared it anywhere else, here is a link to a set of high-resolution cube maps that works with the current engine. This is to show what Vega Strike looks like with high resolution cube maps.

https://drive.google.com/drive/folders/1AmNTCTmfcTeVDEYRMo6KZfTgLol3RzgZ?usp=sharing

Most were generated with the online utility that I referenced earlier. This set also includes the high resolution ray traces of the maps that I managed to get to ray-trace. Lastly, Sol has the actual star map as it's seen from Earth today.

In order to install it, just extract the files (They expand to about 1.9Gb) and overwrite the files of the same name in game assets.

[BenjamenMeyer]

if we can generate, then perhaps we save the seed with the game data and do the generation of systems for the story line on install; non-story line systems could be a mix of stored seed and random seed based on what we provide. This would go a long way towards having a common universe as a base; it'd also be extremely helpful when we get back to networked game play where we could share the seeds.