In the LOD example, I found that two meshes are in the same location and overlap. I did not change any values in the configuration file.

building_blocks_storage-0.2.0\src\chunk_map.rs:467:41
|
467 | chunks: CompressibleFnvMap::from_all_compressed(params, all_compressed),
| ^^^^^^^^^^^^^^^^^^^ function or associated item not found in compressible_map::CompressibleMap<_, _, _, std::hash::BuildHasherDefault<fnv::FnvHasher>>

error: aborting due to previous error

For more information about this error, try rustc --explain E0599.
error: could not compile building_blocks_storage.dHasherDefaultfnv::FnvHasher>`

When trying to build with 0.2

First off - thank you for this crate!

When building for WASM I run into the following error:

error: failed to run custom build command for `lz4-sys v1.9.2`

Caused by:
  process didn't exit successfully: `/xxxxxxx/target/debug/build/lz4-sys-45650fce57a5b4fe/build-script-build` (exit code: 1)
  --- stdout
  TARGET = Some("wasm32-unknown-unknown")
  HOST = Some("x86_64-unknown-linux-gnu")
  CC_wasm32-unknown-unknown = None
  CC_wasm32_unknown_unknown = None
  TARGET_CC = None
  CC = None
  CFLAGS_wasm32-unknown-unknown = None
  CFLAGS_wasm32_unknown_unknown = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  running: "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "--target=wasm32-unknown-unknown" "-Wall" "-Wextra" "-o" "/xxxxxx/wasm32-unknown-unknown/debug/build/lz4-sys-b5586b91058cef1c/out/liblz4/lib/lz4.o" "-c" "liblz4/lib/lz4.c"

  --- stderr


  error occurred: Failed to find tool. Is `clang` installed?

My guess is that we would have to replace the lz4-sys crate with pure Rust implementation?

Hey there! I was looking into this library and I found this line in the docs:

Indexing assumes that the coordinates are in-bounds of the array, panicking otherwise. Bounds checking is only enabled in debug mode.

I was wondering what that meant would happen when indexing out-of-bounds on release builds. Would indexing out-of-bounds be unsafe in release builds?

I know this is planned, but I have an idea on how to do this that I like to share, although I haven't managed to implement it myself.

A cheap trick I found to work with marching cubes is skirts.
It works by simply running marching squares on the faces of the chunk, and then making an extra quad if the cell the face belongs to is active, resulting in something that looks like this:

It's not perfect, but it hides the edges quite well for what it is, especially if the skirts have the same normal as the face they are attached to.

My idea was to adapt this to surface nets as well
I haven't managed to get this working however.
Running 2d surface nets on the chunk faces doesn't work 100%, because it misses the chunk corners, and I haven't managed to get the regular 3d surface nets connected to the face either.

Hello,

could you give some pointers on how to migrate to the new stack?

I used building-blocks in my project some time ago, and now I'm wondering how to migrate to bonsairobo/my-stack. I'm not sure what is the best way to do that, and I'm not very familiar with some concepts, such as localize_points_array . I don't even know which crates to use.

Here are some of the structs, impls and functions I use. I mostly just use building_blocks to generate grids and iterate through them.

• PointN (ilattice?)
• Extent2i::from_min_and_shape, Extent3i::from_min_and_shape (ilattice)
• Extent3i::from_min_and_max (ilattice)
• Array2x1::fill, Array3x1::fill
• Array::extent
• Point3::axis_component_mut
• Local::localize_points_array(&Point3i::MOORE_OFFSETS)
• Array::strides_from_local_points
• Array::for_each

Extents and Points seem to be covered by ilattice, but what about strides? It seems like I might need ndshape-rs. And do these new libraries work with WebAssembly (Never used that before, but I'm intending to) ?

I have code like this. I don't suppose there are drop-in replacements for something like this? (Note: I'm not asking you to rewrite the code for me, I'm just putting it here so that you could give me some pointers):

        let offsets = Local::localize_points_array(&Point3i::MOORE_OFFSETS);
        let mut neighbor_strides = [Stride(0); Point3i::MOORE_OFFSETS.len()];
        self.array.strides_from_local_points(&offsets, &mut neighbor_strides);

        let mut make_surfaces = Vec::new();

        let iter_ext = Extent3i::from_min_and_max(Point3i::fill(1), arr_ext.max() - Point3i::fill(1));

        self.array.for_each(&iter_ext, |stride: Stride, value| {
            if value != NON_EMPTY {
                return;
            }

            for offset in neighbor_strides.iter() {
                let adjacent_value = self.array.get(stride + *offset);
                if adjacent_value == OUTSIDE {
                    make_surfaces.push(stride);
                    return;
                }
            }
        });

        for stride in make_surfaces {
            let val = self.array.get_mut(stride);
            *val = SURFACE;
        }

Thanks

Can simdnoise be feature gated in crates/utilities/Cargo.toml?

Cause it does not compile on a M1 Mac. There is a PR for it to be fixed, but it's getting old : verpeteren/rust-simd-noise#34

When I try to run cargo test on my M1 I get hundreds of errors like this:

323 | #[target_feature(enable = "sse4.1")]
        |              ^^^^^^^^^^^^^^^^^ `sse4.1` is not valid for this target```

I am trying to switch to Snappy (to run as wasm). I have:

      let map: SerializableChunkMap<[i32; 3], f32, (), Snappy> =
        bincode::deserialize(&terrain_res.data[..]).unwrap();

Am getting this error:

error[E0277]: the trait bound `building_blocks::prelude::Snappy: Deserialize<'_>` is not satisfied
   --> src\terrain\terrain.rs:128:9
    |
128 |         bincode::deserialize(&terrain_res.data[..]).unwrap();
    |         ^^^^^^^^^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `building_blocks::prelude::Snappy`

Edit: Tested with Lz4 and same issue occurs as well.

Add a constructor to GreedyQuadsBuffer to allow for custom Axis3Permutation

👋 Hey there!

I tried running the example and ran into some potential issues.

What happens when I run the example:

What I expected from the docs:

System Info:

OS Name	Microsoft Windows 10 Home
Version	10.0.19044 Build 19044
Other OS Description 	Not Available
OS Manufacturer	Microsoft Corporation
System Name	DESKTOP-PMARINB
System Manufacturer	Gigabyte Technology Co., Ltd.
System Model	B450 I AORUS PRO WIFI
System Type	x64-based PC
System SKU	Default string
Processor	AMD Ryzen 7 3700X 8-Core Processor, 3593 Mhz, 8 Core(s), 16 Logical Processor(s)
BIOS Version/Date	American Megatrends Inc. F50, 11/27/2019
SMBIOS Version	3.2
Embedded Controller Version	255.255
BIOS Mode	UEFI
BaseBoard Manufacturer	Gigabyte Technology Co., Ltd.
BaseBoard Product	B450 I AORUS PRO WIFI-CF
Installed Physical Memory (RAM)	32.0 GB
Total Physical Memory	32.0 GB
Available Physical Memory	744 MB
Total Virtual Memory	73.9 GB
Available Virtual Memory	7.80 GB
Page File Space	41.9 GB

This project seems very nice; I'm probably going to be using it as a voxel engine for my game (https://github.com/iMplode-nZ/Autofactory), but I need to run collisions between two different voxel grids, in which the grids can be split up. Will building-blocks support this or will I have to implement it myself? (Side note: It seems that this is most optimal in an octree representation of voxels)

This project seems nice; I think it should have some sort of chat (it seems Discord is generally accepted among the rust community)

I have a use-case where I need to generate a 2D navigation mesh for a non-voxel game. Currently I have a mesh that looks like this ( pardon the green line and paused icon ):

The issue I have is that the navigation mesh is way higher resolution than it needs to be. Those great swaths of terain with no obstacles in them are represented by many more triangles than necessary.

I noticed in your voxel meshing example, the example seems to optimize the mesh properly for the areas that are solid surfaces, not using more triangles than necessary:

Looking at the greedy_quads algorithm, though, it only takes a 3D voxel array.

Do you think this is a proper use-case for building-blocks and if so, do you think we could make the greedy_quads function generic over 2D and 3D or else make a 2D version? Or is there a simple way for me to convert my 2D data to 3D before feeding it to greedy quads, andthen only taking the quads that I want out of it to get a 2D surface?

Hello! I've really been enjoying using this library so far. Was looking at the pathfinding algorithms and noticed building-blocks doesn't have astar yet. Is that something you're interested in including? If so, I'd be open to working on integrating it from pathfinding.

Just a heads up: the links to 'access traits' and 'chunk map' under 'Getting Started' on the main docs.rs page lead to unavailable resources. Also the page is titled 'Crate building_blocks', but the crate is actually called 'building-blocks'; I don't know if this is a limitation of docs.rs, an issue with this project, or my own misunderstanding, but I did take a couple minutes figuring out why my Cargo.toml wasn't working so I figured it was worth mentioning.

Edit: I see that the links have been fixed in this repository already, sorry.

As it says in the title. It's fairly easy to confirm this by changing that constant and running the example.

No leads on the root cause yet.

It seems like there are two issues contributing to the artifacts:

1. Non-manifold complexes
2. Interpolation between "unlit" normals and "lit" normals

When you see random isolated black spots that seem like they should be lit, it's because the vertex is actually non-manifold, and its normal was estimated to point more in the "unlit" direction than the "lit" direction.

Then the interpolation will make that darkness bleed out where it might not makes sense. In particular, on sharp edges. If the normal is estimated as "unlit" that will bleed around the edge.

I think the sharp edge issue is actually a bigger problem. Non-manifold complexes are always undesirable. But sharp edges are certainly something we would like to look correct.