Distant Worlds 2 - Dev Diary #3

[elliotg]

ORIGINAL: TSBasilisk
For drawing your own custom planets, is that able to benefit from the secondary features of the fractal generation - city lights, clouds, etc.? I imagine you'd have something like that for any unique planets you might add to the game, such as homeworlds. Would you need to create a height map to accompany the terrain drawing for example or would the engine be able to do that on its own?

If you want to use the built-in procedural planet or star shaders then you get access to all of the rendering features. But if you choose to use static textures, then the following features could still work with it:
- animated cloud layers
- atmospheric haze
- planetary rings

The city night lights and terrain shadowing rely on the procedural height map, which you forgo if you choose to instead use static textures. Of course along with the static textures you would have access to all the standard material features: normal maps, emissive maps, specularity, etc.

[TSBasilisk]

Thanks for the insight; I expected there'd be some trade-off.

[Hanekem]

This sounds kinda awesome, on the technical level
on the player level, I am ambivalent, eye candy is always nice but my experience with DW I rarely tended to be zoomed into things.
Frankly, I'd rather have quick and easy visibility that gives me substantial info, so a type of planet needs to be very distinct from the next. Admittedly, the eye candy is nice and helps with the immersion, and I am sure it will help with the game's first impression

Don't get me wrong, it looks amazing, and I'll love to see it in game, but it is bling, nice bling, but ultimately bling.
I'd rather have celestial mechanics than unique looking planets, tbh.

But I'll easily admit this is more likely to bring in customers

[SirHoraceHarkness]

This is one I don't think people have asked about but will there be the ability to make system templates for galaxy creation? As in you recreate the solar system and the game will use that as your starting system if you pick humans? It could also help to make galaxy creation a little less random by having a certain amount of systems contents predetermined.

[elliotg]

ORIGINAL: SirHoraceHarkness
This is one I don't think people have asked about but will there be the ability to make system templates for galaxy creation? As in you recreate the solar system and the game will use that as your starting system if you pick humans? It could also help to make galaxy creation a little less random by having a certain amount of systems contents predetermined.

We have that kind of thing available from the Game Event system, and we use it for some of the story events. This mechanism could be used to modify the player's starting system. It's not so much a star system template as the ability to add new planets to a system.

[Lobster]

No Man's Sky uses procedural rendering. Only way you can have quitillions of planets.

Looking foward to DW2

[Rising-Sun]

ORIGINAL: Lobster

No Man's Sky uses procedural rendering. Only way you can have quitillions of planets.

Looking foward to DW2

Been playing that game, it is interesting, but not realistic. Been trying to find a way to enjoy it as single play in survival mode.

[dawilko]

Love the update, thankyou for sharing.

[zgrssd]

ORIGINAL: elliotg

ORIGINAL: TSBasilisk
For drawing your own custom planets, is that able to benefit from the secondary features of the fractal generation - city lights, clouds, etc.? I imagine you'd have something like that for any unique planets you might add to the game, such as homeworlds. Would you need to create a height map to accompany the terrain drawing for example or would the engine be able to do that on its own?

If you want to use the built-in procedural planet or star shaders then you get access to all of the rendering features. But if you choose to use static textures, then the following features could still work with it:
- animated cloud layers
- atmospheric haze
- planetary rings

The city night lights and terrain shadowing rely on the procedural height map, which you forgo if you choose to instead use static textures. Of course along with the static textures you would have access to all the standard material features: normal maps, emissive maps, specularity, etc.

Some questions:
1. Could you allow modders to manually define a height map? You already planned for hand-drawn textures, the height-map would be just another input.
Actually providing the custom height map might be more interesting in the first place: Being able to see the same topography in different climates and levels of colonisation might be interesting.

2. Will it be possible to extract the Seeds for each procedural step from a existing games planet?
Effectively giving us a way to "re-use" a well generated world in future maps via map editing?
This would also be nessesary for bugfixing, as the procedural drawing code might break.

[elliotg]

ORIGINAL: zgrssd

ORIGINAL: elliotg

ORIGINAL: TSBasilisk
For drawing your own custom planets, is that able to benefit from the secondary features of the fractal generation - city lights, clouds, etc.? I imagine you'd have something like that for any unique planets you might add to the game, such as homeworlds. Would you need to create a height map to accompany the terrain drawing for example or would the engine be able to do that on its own?

If you want to use the built-in procedural planet or star shaders then you get access to all of the rendering features. But if you choose to use static textures, then the following features could still work with it:
- animated cloud layers
- atmospheric haze
- planetary rings

The city night lights and terrain shadowing rely on the procedural height map, which you forgo if you choose to instead use static textures. Of course along with the static textures you would have access to all the standard material features: normal maps, emissive maps, specularity, etc.

Some questions:
1. Could you allow modders to manually define a height map? You already planned for hand-drawn textures, the height-map would be just another input.
Actually providing the custom height map might be more interesting in the first place: Being able to see the same topography in different climates and levels of colonisation might be interesting.

The height map is tightly integrated with the rest of the procedural rendering. It is not a static thing, but is dynamically generated for each pixel when rendering the planet. So no, it is not possible to supply this externally. You have to choose either static planet drawing or leveraging the built-in procedural planet rendering.

2. Will it be possible to extract the Seeds for each procedural step from a existing games planet?
Effectively giving us a way to "re-use" a well generated world in future maps via map editing?
This would also be nessesary for bugfixing, as the procedural drawing code might break.

It may be possible to do something like this in the future, however there is more than just a single seed value that defines the appearance of the planet. The planet type itself (volcanic, ocean, etc) defines a set of values, including the actual procedural shader selected. So all of these values work together to render the planet.

[zgrssd]

ORIGINAL: elliotg

2. Will it be possible to extract the Seeds for each procedural step from a existing games planet?
Effectively giving us a way to "re-use" a well generated world in future maps via map editing?
This would also be nessesary for bugfixing, as the procedural drawing code might break.

It may be possible to do something like this in the future, however there is more than just a single seed value that defines the appearance of the planet. The planet type itself (volcanic, ocean, etc) defines a set of values, including the actual procedural shader selected. So all of these values work together to render the planet.

If the heightmap can not be declared (as it is calculated), that would make storing the seed for the heightmap all the more important.
Given you can store and retreive the seed data via savegames, it should not be impossible to expose it to the Clipboard either.

Without city night lights and terrain shadowing, planet textures just will not be usefull for custom planets. They would inherently look worse then their procedural counterparts. There is a reason you only use them for Asteroids. [;)]

I do forsee this becomming a critical issue for the modding community.

[zgrssd]

Without city night lights and terrain shadowing, planet textures just will not be usefull for custom planets. They would inherently look worse then their procedural counterparts. There is a reason you only use them for Asteroids.

I do forsee this becomming a critical issue for the modding community.

I think I should elaborate on this. I understand why you did it from a production perspective. But I also forsee 3 ways this could affect the modding community and thus the game:
1. The inability to make a remotely decent looking Solar System/Earth will turn away graphic modders. Which would negatively impact the longterm survival of the game.

Retexturing a colonizable planet without it looking like crap in the game. This should be around "Hello World" in difficulty. But I doubt it will even be possible in the game.

2. There will be a thread looking for "the closes approximation to earth".
Where people will exchange the inputs for the procedural generation that will closest represent earth. So they can have "almsot earths" in their galactic maps.

3. You give us at least some way to bodge the planet
- You can not give us a scaling heightmap (as those have to be procedurally generated), but what about a low detail heightmap of earth? Not a lot of the mountains throw shadows that can be seen from space. Even this image is only 254 KiB in size and has a lot of excessive detail. My instinct tells me we would only need 2 bits per pixel (Mountain visible from space, Land, Ocean, Deep Ocean). Any missing details could be interpolated from that.
- Maybe a static "city map" for populated planets, that is masked by the day/night cycle?
- Maybe a static cloud layer, that just rotates around the planet?


I hope I am wrong with Option 1. But I fear that you need to have 2 or 3 ready around release.

[elliotg]

ORIGINAL: zgrssd

Without city night lights and terrain shadowing, planet textures just will not be usefull for custom planets. They would inherently look worse then their procedural counterparts. There is a reason you only use them for Asteroids.

I do forsee this becomming a critical issue for the modding community.

I think I should elaborate on this. I understand why you did it from a production perspective. But I also forsee 3 ways this could affect the modding community and thus the game:
1. The inability to make a remotely decent looking Solar System/Earth will turn away graphic modders. Which would negatively impact the longterm survival of the game.

Retexturing a colonizable planet without it looking like crap in the game. This should be around "Hello World" in difficulty. But I doubt it will even be possible in the game.

2. There will be a thread looking for "the closes approximation to earth".
Where people will exchange the inputs for the procedural generation that will closest represent earth. So they can have "almsot earths" in their galactic maps.

3. You give us at least some way to bodge the planet
- You can not give us a scaling heightmap (as those have to be procedurally generated), but what about a low detail heightmap of earth? Not a lot of the mountains throw shadows that can be seen from space. Even this image is only 254 KiB in size and has a lot of excessive detail. My instinct tells me we would only need 2 bits per pixel (Mountain visible from space, Land, Ocean, Deep Ocean). Any missing details could be interpolated from that.
- Maybe a static "city map" for populated planets, that is masked by the day/night cycle?
- Maybe a static cloud layer, that just rotates around the planet?


I hope I am wrong with Option 1. But I fear that you need to have 2 or 3 ready around release.

Not sure if you missed the part earlier in the thread where static planets have full access to all of the material features of Stride (the rendering engine). So not just diffuse, but normal maps, specularity, emissive, etc. So you can effectively do your own 'height map' using normal map, micro surface, etc.

See the Stride documentation for details: https://doc.stride3d.net/latest/en/manual/graphics/materials/material-attributes.html

Thanks
Elliot