Mirrored_Repos/veloren
1
0
Fork 0
mirror of https://gitlab.com/veloren/veloren.git synced 2024-08-30 18:12:32 +00:00
Code Issues Packages Projects Releases Wiki Activity
c11b9bdf0a
veloren/world/examples/water.rs

393 lines
14 KiB
Rust
Raw Normal View History

Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
use common::{
terrain::{
map::{MapConfig, MapDebug, MapSample},
uniform_idx_as_vec2, vec2_as_uniform_idx, TerrainChunkSize,
},
vol::RectVolSize,
};
Adding shadows.
2020-02-21 13:52:17 +00:00
use rayon::prelude::*;
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
use std::{f64, io::Write, path::PathBuf, time::SystemTime};
Convert all other veloren crates to use tracing - Completely removed both `log` and `pretty_env_logger` and replaced with `tracing` and `tracing_subscriber` where necessary. - Converted all `log::info!(...)` et al. statements to just use the shorthand macro i.e. `info!`. This was mostly to make renaming easier.
2020-06-21 14:26:06 +00:00
use tracing::warn;
use tracing_subscriber;
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
use vek::*;
use veloren_world::{
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
sim::{self, get_horizon_map, sample_pos, sample_wpos, WorldOpts},
Adding shadows.
2020-02-21 13:52:17 +00:00
util::Sampler,
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
ColumnSample, World, CONFIG,
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
};
const W: usize = 1024;
const H: usize = 1024;
Suppressed all existing clippy warnings in preparation for fixes as part of #587
2020-06-10 19:47:36 +00:00
#[allow(clippy::needless_update)] // TODO: Pending review in #587
#[allow(clippy::unused_io_amount)] // TODO: Pending review in #587
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
fn main() {
Convert all other veloren crates to use tracing - Completely removed both `log` and `pretty_env_logger` and replaced with `tracing` and `tracing_subscriber` where necessary. - Converted all `log::info!(...)` et al. statements to just use the shorthand macro i.e. `info!`. This was mostly to make renaming easier.
2020-06-21 14:26:06 +00:00
tracing_subscriber::fmt::init();
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
// To load a map file of your choice, replace map_file with the name of your map
// (stored locally in the map directory of your Veloren root), and swap the
// sim::FileOpts::Save line below for the sim::FileOpts::Load one.
Map saving, soil production, speedup attempts.
2019-12-11 09:14:50 +00:00
let map_file =
// "map_1575990726223.bin";
// "map_1575987666972.bin";
Adding shadows.
2020-02-21 13:52:17 +00:00
// "map_1576046079066.bin";
Enable loading different sized maps without a recompile. We may want to tweak the effects of the continent_scale_hack.
2020-07-28 10:11:40 +00:00
// "maps/071090_2x.bin";
Adding shadows.
2020-02-21 13:52:17 +00:00
"map_1579539133272.bin";
Map saving, soil production, speedup attempts.
2019-12-11 09:14:50 +00:00
let mut _map_file = PathBuf::from("./maps");
_map_file.push(map_file);
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
let world = World::generate(5284, WorldOpts {
seed_elements: false,
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
world_file: sim::FileOpts::LoadAsset(veloren_world::sim::DEFAULT_WORLD_MAP.into()),
// world_file: sim::FileOpts::Load(_map_file),
Adding shadows.
2020-02-21 13:52:17 +00:00
// world_file: sim::FileOpts::Save,
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
..WorldOpts::default()
});
Revert some irrelevant stuff.
2020-07-15 23:57:39 +00:00
tracing::info!("Sampling data...");
Adding shadows.
2020-02-21 13:52:17 +00:00
let sampler = world.sim();
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let map_size_lg = sampler.map_size_lg();
Adding shadows.
2020-02-21 13:52:17 +00:00
let samples_data = {
let column_sample = world.sample_columns();
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
(0..map_size_lg.chunks_len())
Adding shadows.
2020-02-21 13:52:17 +00:00
.into_par_iter()
.map(|posi| {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
column_sample.get(
uniform_idx_as_vec2(map_size_lg, posi)
* TerrainChunkSize::RECT_SIZE.map(|e| e as i32),
)
Adding shadows.
2020-02-21 13:52:17 +00:00
})
.collect::<Vec<_>>()
.into_boxed_slice()
};
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let refresh_map_samples = |config: &MapConfig, samples: Option<&[Option<ColumnSample>]>| {
(0..map_size_lg.chunks_len())
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
.into_par_iter()
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
.map(|posi| {
sample_pos(
config,
sampler,
samples,
uniform_idx_as_vec2(map_size_lg, posi),
)
})
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
.collect::<Vec<_>>()
.into_boxed_slice()
};
let get_map_sample = |map_samples: &[MapSample], pos: Vec2<i32>| {
if pos.reduce_partial_min() >= 0
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
&& pos.x < map_size_lg.chunks().x as i32
&& pos.y < map_size_lg.chunks().y as i32
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
{
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
map_samples[vec2_as_uniform_idx(map_size_lg, pos)].clone()
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
} else {
MapSample {
alt: 0.0,
rgb: Rgb::new(0, 0, 0),
connections: None,
downhill_wpos: (pos + 1) * TerrainChunkSize::RECT_SIZE.map(|e| e as i32),
}
}
};
Adding shadows.
2020-02-21 13:52:17 +00:00
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let refresh_horizons = |is_basement, is_water| {
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
get_horizon_map(
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
map_size_lg,
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
Aabr {
min: Vec2::zero(),
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
max: map_size_lg.chunks().map(|e| e as i32),
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
},
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
CONFIG.sea_level,
CONFIG.sea_level + sampler.max_height,
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
|posi| {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let sample = sampler.get(uniform_idx_as_vec2(map_size_lg, posi)).unwrap();
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
if is_basement {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
sample.alt
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
} else {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
sample.basement
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
}
.max(if is_water {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
sample.water_alt
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
} else {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
-f32::INFINITY
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
})
},
|a| a,
|h| h,
/* |[al, ar]| [al, ar],
* |[hl, hr]| [hl, hr], */
)
.ok()
Adding shadows.
2020-02-21 13:52:17 +00:00
};
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
let mut win =
minifb::Window::new("World Viewer", W, H, minifb::WindowOptions::default()).unwrap();
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
let mut focus = Vec3::new(0.0, 0.0, CONFIG.sea_level as f64);
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
// Altitude is divided by gain and clamped to [0, 1]; thus, decreasing gain
// makes smaller differences in altitude appear larger.
Adding shadows.
2020-02-21 13:52:17 +00:00
let mut gain = /*CONFIG.mountain_scale*/sampler.max_height;
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
// The Z component during normal calculations is multiplied by gain; thus,
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let mut fov = 1.0;
Fix map image artifacts and remove unneeded allocations. Specifically, we address three concerns (the image stretching during rotation, artifacts around the image due to clamping to the nearest border color when the image is drawn to a larger space than the image itself takes up, and potential artifacts around a rotated image which accidentally ended up in an atlas and didn't have enough extra space to guarantee the rotation would work). The first concern was addressed by fixing the dimensions of the map images drawn from the UI (so that we always use a square source rectangle, rather than a rectangular one according to the dimensions of the map). We also fixed the way rotation was done in the fragment shader for north-facing sources to make it properly handle aspect ratio (this was already done for north-facing targets). Together, these fix rendering issues peculiar to rectangular maps. The second and third concerns were jointly addressed by adding an optional border color to every 2D image drawn by the UI. This turns out not to waste extra space even though we hold a full f32 color (to avoid an extra dependency on gfx's PackedColor), since voxel images already take up more space than Optiion<[f32; 4]> requires. This is then implemented automatically using the "border color" wrapping method in the attached sampler. Since this is implemented in graphics hardware, it only works (at least naively) if the actual image bounds match the texture bounds. Therefore, we altered the way the graphics cache stores images with a border color to guarantee that they are always in their own texture, whose size exactly matches their extent. Since the easiest currently exposed way to set a border color is to do so for an immutable texture, we went a bit further and added a new "immutable" texture storage type used for these cases; currently, it is always and automatically used only when there is a specified border color, but in theory there's no reason we couldn't provide immutable-only images that use the default wrapping mdoe (though clamp to border is admittedly not a great default). To fix the maps case specifically, we set the border color to a translucent version of the ocean border color. This may need tweaking going forward, which shouldn't be hard. As part of this process, we had to modify graphics replacement to make sure immutable images are *removed* when invalidated, rather than just having a validity flag unset (this is normally done by the UI to try to reuse allocations in place if images are updated in benign ways, since the texture atlases used for Ui do not support deallocation; currently this is only used for item images, so there should be no overlap with immutable image replacement, so this was purely precautionary). Since we were already touching the relevant code, we also updated the image dependency to a newer version that provides more ways to avoid allocations, and made a few other changes that should hopefully eliminate redundant most of the intermediate buffer allocations we were performing for what should be zero-cost conversions. This may slightly improve performance in some cases.
2020-07-29 16:29:52 +00:00
let mut scale =
(map_size_lg.chunks().x as f64 / W as f64).max(map_size_lg.chunks().y as f64 / H as f64);
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
// Right-handed coordinate system: light is going left, down, and "backwards"
// (i.e. on the map, where we translate the y coordinate on the world map to
// z in the coordinate system, the light comes from -y on the map and points
// towards +y on the map). In a right handed coordinate system, the
// "camera" points towards -z, so positive z is backwards "into" the camera.
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
//
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
// "In world space the x-axis will be pointing east, the y-axis up and the
// z-axis will be pointing south"
Adding shadows.
2020-02-21 13:52:17 +00:00
let mut light_direction = Vec3::new(-/*0.8*/1.3, -1.0, 0.3);
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
Adding hillslope diffusion.
2019-11-19 18:34:52 +00:00
let mut is_basement = false;
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
let mut is_water = true;
Map fixes.
2019-11-20 03:39:17 +00:00
let mut is_shaded = true;
let mut is_temperature = true;
let mut is_humidity = true;
Adding hillslope diffusion.
2019-11-19 18:34:52 +00:00
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let mut horizons = refresh_horizons(is_basement, is_water);
Adding shadows.
2020-02-21 13:52:17 +00:00
let mut samples = None;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
let mut samples_changed = true;
let mut map_samples: Box<[_]> = Box::new([]);
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
while win.is_open() {
Send client 3D rendered map. Also shares configurable rendering between map generator and server.
2020-01-13 07:10:38 +00:00
let config = MapConfig {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
map_size_lg,
Send client 3D rendered map. Also shares configurable rendering between map generator and server.
2020-01-13 07:10:38 +00:00
dimensions: Vec2::new(W, H),
focus,
gain,
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
fov,
Send client 3D rendered map. Also shares configurable rendering between map generator and server.
2020-01-13 07:10:38 +00:00
scale,
light_direction,
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
horizons: horizons.as_ref(), /* .map(|(a, b)| (&**a, &**b)) */
Send client 3D rendered map. Also shares configurable rendering between map generator and server.
2020-01-13 07:10:38 +00:00
is_basement,
is_water,
is_shaded,
is_temperature,
is_humidity,
is_debug: true,
};
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
if samples_changed {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
map_samples = refresh_map_samples(&config, samples);
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
};
Send client 3D rendered map. Also shares configurable rendering between map generator and server.
2020-01-13 07:10:38 +00:00
let mut buf = vec![0; W * H];
let MapDebug {
rivers,
lakes,
oceans,
quads,
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
} = config.generate(
|pos| get_map_sample(&map_samples, pos),
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
|pos| sample_wpos(&config, sampler, pos),
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
|pos, (r, g, b, a)| {
let i = pos.x;
let j = pos.y;
buf[j * W + i] = u32::from_le_bytes([b, g, r, a]);
},
);
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
if win.is_key_down(minifb::Key::F4) {
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
// Feedback is important since on large maps it can be hard to tell if the
// keypress registered or not.
println!("Taking screenshot...");
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
if let Some(len) = (W * H)
.checked_mul(scale as usize)
.and_then(|acc| acc.checked_mul(scale as usize))
{
Minor fix to map generation. Also fixes some typos and makes formatting easier for changes needed to produce large maps.
2020-01-22 09:41:10 +00:00
let x = (W as f64 * scale) as usize;
let y = (H as f64 * scale) as usize;
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
let config = MapConfig {
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
dimensions: Vec2::new(x, y),
scale: 1.0,
..config
};
let mut buf = vec![0u8; 4 * len];
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
config.generate(
|pos| get_map_sample(&map_samples, pos),
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
|pos| sample_wpos(&config, sampler, pos),
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
|pos, (r, g, b, a)| {
let i = pos.x;
let j = pos.y;
(&mut buf[(j * x + i) * 4..]).write(&[r, g, b, a]).unwrap();
},
);
Erosion cleanup, part 1. Covers all files touched by MR that are not in world/src/sim.
2020-01-22 13:35:13 +00:00
// TODO: Justify fits in u32.
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
let world_map = image::RgbaImage::from_raw(x as u32, y as u32, buf)
.expect("Image dimensions must be valid");
let mut path = PathBuf::from("./screenshots");
if !path.exists() {
switch to `tracing` stlye and enhance logs with usefull information - Updated CHANGELOG - reduce dependencies - found out that we have alot of duplicate coding... alot...
2020-06-21 21:47:49 +00:00
if let Err(e) = std::fs::create_dir(&path) {
warn!(?e, ?path, "Couldn't create folder for screenshot");
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
}
}
path.push(format!(
"worldmap_{}.png",
SystemTime::now()
.duration_since(SystemTime::UNIX_EPOCH)
.map(|d| d.as_millis())
.unwrap_or(0)
));
switch to `tracing` stlye and enhance logs with usefull information - Updated CHANGELOG - reduce dependencies - found out that we have alot of duplicate coding... alot...
2020-06-21 21:47:49 +00:00
if let Err(e) = world_map.save(&path) {
warn!(?e, ?path, "Couldn't save screenshot");
Screenshots with F4 in the map, that will have the full resolution of the displayed map (hopefully).
2020-01-20 20:17:55 +00:00
}
}
}
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
let spd = 32.0;
let lspd = 0.1;
Reverting changes except to humidity and temperature noise.
2019-11-07 20:25:30 +00:00
if win.is_key_down(minifb::Key::P) {
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
println!(
"\
apply new rustfmt - touching alot of files
2020-02-01 20:39:39 +00:00
Gain / Shade gain: {:?} / {:?}\nScale / Focus: {:?} / {:?}\nLight: {:?}
Land(adjacent): (X = temp, Y = humidity): {:?}\nRivers: {:?}\nLakes: \
{:?}\nOceans: {:?}\nTotal water: {:?}\nTotal land(adjacent): {:?}",
Implement carving strategy for lake connections. Also fix mapgen slopes and make a much more pleasing world.
2019-11-22 02:55:19 +00:00
gain,
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
fov,
Implement carving strategy for lake connections. Also fix mapgen slopes and make a much more pleasing world.
2019-11-22 02:55:19 +00:00
scale,
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
focus,
light_direction,
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
quads,
rivers,
lakes,
oceans,
Reverting changes except to humidity and temperature noise.
2019-11-07 20:25:30 +00:00
rivers + lakes + oceans,
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
quads.iter().map(|x| x.iter().sum::<u32>()).sum::<u32>()
Reverting changes except to humidity and temperature noise.
2019-11-07 20:25:30 +00:00
);
}
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
if win.get_mouse_down(minifb::MouseButton::Left) {
if let Some((mx, my)) = win.get_mouse_pos(minifb::MouseMode::Clamp) {
Add more crops
2020-04-17 23:29:01 +00:00
let chunk_pos = (Vec2::<f64>::from(focus)
+ (Vec2::new(mx as f64, my as f64) * scale))
Send client 3D rendered map. Also shares configurable rendering between map generator and server.
2020-01-13 07:10:38 +00:00
.map(|e| e as i32);
Began work on basic economic simulation
2020-03-27 23:06:23 +00:00
let block_pos = chunk_pos.map2(TerrainChunkSize::RECT_SIZE, |e, f| e * f as i32);
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
println!(
Add more crops
2020-04-17 23:29:01 +00:00
"Block: ({}, {}), Chunk: ({}, {})",
block_pos.x, block_pos.y, chunk_pos.x, chunk_pos.y
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
);
Began work on basic economic simulation
2020-03-27 23:06:23 +00:00
if let Some(chunk) = sampler.get(chunk_pos) {
//println!("Chunk info: {:#?}", chunk);
Basic trading simulation
2020-03-28 18:16:19 +00:00
if let Some(id) = &chunk.place {
let place = world.civs().place(*id);
println!("Place {} info: {:#?}", id.id(), place);
Overhauled domestic economy simulation, better debug information
2020-03-30 16:46:44 +00:00
if let Some(site) = world.civs().sites().find(|site| site.place == *id) {
println!("Site: {}", site);
}
Began work on basic economic simulation
2020-03-27 23:06:23 +00:00
}
}
WIP fixes: more pleasing uplift generation. Uses the exponential distribution now.
2019-11-11 17:14:58 +00:00
}
}
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
let is_camera = win.is_key_down(minifb::Key::C);
Adding hillslope diffusion.
2019-11-19 18:34:52 +00:00
if win.is_key_down(minifb::Key::B) {
is_basement ^= true;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
horizons = horizons.and_then(|_| refresh_horizons(is_basement, is_water));
Adding hillslope diffusion.
2019-11-19 18:34:52 +00:00
}
Map fixes.
2019-11-20 03:39:17 +00:00
if win.is_key_down(minifb::Key::H) {
is_humidity ^= true;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Map fixes.
2019-11-20 03:39:17 +00:00
}
if win.is_key_down(minifb::Key::T) {
is_temperature ^= true;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Map fixes.
2019-11-20 03:39:17 +00:00
}
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if win.is_key_down(minifb::Key::O) {
is_water ^= true;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
horizons = horizons.and_then(|_| refresh_horizons(is_basement, is_water));
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
}
Map fixes.
2019-11-20 03:39:17 +00:00
if win.is_key_down(minifb::Key::L) {
Adding shadows.
2020-02-21 13:52:17 +00:00
if is_camera {
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
// TODO: implement removing horizon mapping.
Making maps brighter. This is probably not the right way to do it, but oh well!
2020-04-02 01:17:49 +00:00
horizons = if horizons.is_some() {
None
} else {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
refresh_horizons(is_basement, is_water)
Making maps brighter. This is probably not the right way to do it, but oh well!
2020-04-02 01:17:49 +00:00
};
samples_changed = true;
Adding shadows.
2020-02-21 13:52:17 +00:00
} else {
is_shaded ^= true;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Adding shadows.
2020-02-21 13:52:17 +00:00
}
}
if win.is_key_down(minifb::Key::M) {
samples = samples.xor(Some(&*samples_data));
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Map fixes.
2019-11-20 03:39:17 +00:00
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
if win.is_key_down(minifb::Key::W) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
light_direction.z -= lspd;
} else {
focus.y -= spd * scale;
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::A) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
light_direction.x -= lspd;
} else {
focus.x -= spd * scale;
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::S) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
light_direction.z += lspd;
} else {
focus.y += spd * scale;
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::D) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
light_direction.x += lspd;
} else {
focus.x += spd * scale;
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::Q) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
if (fov * 2.0).is_normal() {
fov *= 2.0;
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
}
} else {
gain += 64.0;
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::E) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
Removing WORLD_SIZE, part 1. Erased almost every instance of WORLD_SIZE and replaced it with a local power of two, map_size_lg (which respects certain invariants; see common/src/terrain/map.rs for more details about MapSizeLg). This also means we can avoid a dependency on the world crate from client, as desired. Now that the rest of the code is not expecting a fixed WORLD_SIZE, the next step is to arrange for maps to store their world size, and to use that world size as a basis prior to loading the map (as well, probably, as prior to configuring some of the noise functions).
2020-07-28 08:55:48 +00:00
if (fov / 2.0).is_normal() {
fov /= 2.0;
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
}
} else {
gain = (gain - 64.0).max(64.0);
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::R) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
focus.z += spd * scale;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
} else {
if (scale * 2.0).is_normal() {
scale *= 2.0;
}
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
if win.is_key_down(minifb::Key::F) {
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
if is_camera {
focus.z -= spd * scale;
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
samples_changed = true;
Sediment transport, plus many other things.
2019-12-03 01:07:44 +00:00
} else {
if (scale / 2.0).is_normal() {
scale /= 2.0;
}
}
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
Horizon mapping and "layered" map generation. Horizon mapping is a method of shadow mapping specific to height maps. It can handle any angle between 0 and 90 degrees from the ground, as long as know the horizontal direction in advance, by remembering only a single angle (the "horizon angle" of the shadow map). More is explained in common/src/msg/server.rs. We also remember the approximate height of the largest occluder, to try to be able to generate soft shadows and create a vertical position where the shadows can't go higher. Additionally, map generation has been reworked. Instead of computing everything from explicit samples, we pass in sampling functions that return exactly what the map generator needs. This allows us to cleanly separate the way we sample things like altitudes and colors from the map generation process. We exploit this to generate maps *partially* on the server (with colors and rivers, but not shading). We can then send the partially completed map to the client, which can combine it with shadow information to generate the final map. This is useful for two reasons: first, it makes sure the client can apply shadow information by itself, and second, it lets us pass the unshaded map for use with level of detail functionality. For similar reasons, river generation is split out into its own layer, but for now we opt to still generate rivers on the server (since the river wire format is more complicated to compress and may require some extra work to make sure we have enough precision to draw rivers well enough for LoD). Finally, the mostly ad-hoc lighting we were performing has been (mostly) replaced with explicit Phong reflection shading (including specular highlights). Regularizing this seems useful and helps clarify the "meaning" of the various light intensities, and helps us keep a more physically plausible basis. However, its interaction with soft shadows is still imperfect, and it's not yet clear to me what we need to do to turn this into something useful for LoD.
2020-04-02 00:46:36 +00:00
win.update_with_buffer_size(&buf, W, H).unwrap();
Allow canceling chunk generation. Currently we only do this when no players are in range of the chunk. We also send the first client who posted the chunk a message indicating that it's canceled, the hope being that this will be a performance win in single player mode since you don't have to wait three seconds to realize that the server won't generate the chunk for you. We now check an atomic flag for every column sample in a chunk. We could probably do this less frequently, but since it's a relaxed load it has essentially no performance impact on Intel architectures.
2019-10-16 11:39:41 +00:00
}
}
Reference in New Issue Copy Permalink