norman784 / gaiku Goto Github PK

Right now we add a new pair of Position/Normal/UV, we check against all elements to see if they are duplicate or not, this leads to generate a lot of indices and vertices, if we export our mesh to .obj file we get:

o mesh_0
v 1.000000 1.000000 0.000000
v 0.000000 1.000000 0.000000
v 1.000000 1.000000 1.000000
v 0.000000 1.000000 1.000000
v 0.000000 0.000000 0.000000
v 1.000000 0.000000 0.000000
v 0.000000 0.000000 1.000000
v 1.000000 0.000000 1.000000
v 0.000000 1.000000 1.000000
v 0.000000 1.000000 0.000000
v 0.000000 0.000000 1.000000
v 0.000000 0.000000 0.000000
v 1.000000 1.000000 0.000000
v 1.000000 1.000000 1.000000
v 1.000000 0.000000 0.000000
v 1.000000 0.000000 1.000000
v 1.000000 1.000000 1.000000
v 0.000000 1.000000 1.000000
v 1.000000 0.000000 1.000000
v 0.000000 0.000000 1.000000
v 0.000000 1.000000 0.000000
v 1.000000 1.000000 0.000000
v 0.000000 0.000000 0.000000
v 1.000000 0.000000 0.000000
vt 0.000000 0.937500
vt 0.062500 0.937500
vt 0.000000 1.000000
vt 0.062500 1.000000
vt 0.000000 0.937500
vt 0.062500 0.937500
vt 0.000000 1.000000
vt 0.062500 1.000000
vt 0.000000 0.937500
vt 0.062500 0.937500
vt 0.000000 1.000000
vt 0.062500 1.000000
vt 0.000000 0.937500
vt 0.062500 0.937500
vt 0.000000 1.000000
vt 0.062500 1.000000
vt 0.000000 0.937500
vt 0.062500 0.937500
vt 0.000000 1.000000
vt 0.062500 1.000000
vt 0.000000 0.937500
vt 0.062500 0.937500
vt 0.000000 1.000000
vt 0.062500 1.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
f 1/1/1 2/2/2 3/3/3
f 2/2/2 4/4/4 3/3/3
f 5/5/5 6/6/6 7/7/7
f 6/6/6 8/8/8 7/7/7
f 9/9/9 10/10/10 11/11/11
f 10/10/10 12/12/12 11/11/11
f 13/13/13 14/14/14 15/15/15
f 14/14/14 16/16/16 15/15/15
f 17/17/17 18/18/18 19/19/19
f 18/18/18 20/20/20 19/19/19
f 21/21/21 22/22/22 23/23/23
f 22/22/22 24/24/24 23/23/23

While blender generates

o Cube_Cube.001
v -1.000000 -1.000000 1.000000
v -1.000000 1.000000 1.000000
v -1.000000 -1.000000 -1.000000
v -1.000000 1.000000 -1.000000
v 1.000000 -1.000000 1.000000
v 1.000000 1.000000 1.000000
v 1.000000 -1.000000 -1.000000
v 1.000000 1.000000 -1.000000
vt -0.002071 0.500793
vt 0.500071 0.500793
vt 0.500071 1.002934
vt -0.002071 1.002934
vt 0.001491 0.500907
vt 0.498970 0.500907
vt 0.498970 0.998387
vt 0.001491 0.998387
vt 0.000900 0.500561
vt 0.499561 0.500561
vt 0.499561 0.999222
vt 0.000900 0.999222
vt 0.000020 0.503617
vt 0.497980 0.503617
vt 0.497980 1.001577
vt 0.000020 1.001577
vt 0.001347 0.503713
vt 0.496164 0.503713
vt 0.496164 0.998531
vt 0.001347 0.998531
vt 0.004237 0.509806
vt 0.494253 0.509806
vt 0.494253 0.999821
vt 0.004237 0.999821
vn -1.0000 0.0000 0.0000
vn 0.0000 0.0000 -1.0000
vn 1.0000 0.0000 0.0000
vn 0.0000 0.0000 1.0000
vn 0.0000 -1.0000 0.0000
vn 0.0000 1.0000 0.0000
usemtl None
s off
f 1/1/1 2/2/1 4/3/1 3/4/1
f 3/5/2 4/6/2 8/7/2 7/8/2
f 7/9/3 8/10/3 6/11/3 5/12/3
f 5/13/4 6/14/4 2/15/4 1/16/4
f 3/17/5 7/18/5 5/19/5 1/20/5
f 8/21/6 4/22/6 2/23/6 6/24/6

A quick look into Bevy source code seems to not supporting this feature, while in Amethyst I'm not sure, the documentation for the current version is broken in docs.rs and the source code is complicated.

It looks like there are 3d examples one could run but no explanation for how to do so. It'd be great to get these running and add some direction and pictures. Thanks!

So after getting passed my issue in #20 I failed to get a visibile mesh. Since I didn't reach a panic associated with an empty mesh or texture, I assume this is because I have a transparent texture mapped.

Currently I map texture like this:

let mut texture = TextureAtlas2d::new(4);
texture.set_at_index(1, [chunk.color.clone(); 4*4].to_vec());
let options = BakerOptions {
    texture: Some(texture),
    ..Default::default()
};

let mesh_gox =
    VoxelBaker::bake::<NoiseChunk, GaikuTexture2d, GaikuMesh>(&chunk, &options);

let (mesh_data, tex_data) = if let Ok(Some(mesh_gox)) = mesh_gox {
    let tex_data: TextureData = options.texture.unwrap().get_texture().into();
    (mesh_gox.into(), tex_data)
} else {
    unreachable!(); // Should always have a mesh
};

With all chunks returning 1 for the index on get

fn get(&self, x: usize, y: usize, z: usize) -> (u8, u8) {
        if self.is_air(x, y, z) {
            (0, 0)
        } else {
            (1, 1)
        }
    }

Am I misunderstanding something here about how to set the pixels on a voxel?

Hi! Can't compile anything because of this
gox = { path = "../../gox" }

If I uncomment gox = "0.2.0", then compilation fails

error[E0599]: no method named `get_pixel_f32` found for reference `&gox::block::Block` in the current scope
  --> gaiku-3d/src/formats/gox.rs:48:60
   |
48 | ...                   colors.get_pixel_f32(x, y, z).into(),
   |                              ^^^^^^^^^^^^^ help: there is an associated function with a similar name: `get_pixel`

What version of gox there should be? If there is a reason of having some specific version, that can not be handled by cargo, maybe consider using a git module?

Trying to use the latest master with stock Chunk but I am getting OutOfBounds when voxel baking the chunk with dimensions [112, 146, 52].

thread '<unnamed>' panicked at 'Out of bounds MeshBuilderData { position: [5.0, 146.0, 13.0], normal: Some([0.0, 1.0, 0.0]), uv: Some([0.0625, 0.9375]), atlas_index: 1, index: 540 }
', /Users/awk21/Projects/Software/gaiku/gaiku-common/src/mesh.rs:368:36

I think this may be to do with the boundary check not including an epsilon error or the last value

pub fn contains(&self, point: &Vector3<f32>) -> bool {
    self.start.x < point.x
      && self.start.y < point.y
      && self.start.z < point.z
      && self.end.x > point.x
      && self.end.y > point.y
      && self.end.z > point.z
  }

Perhaps something like this?

pub fn contains(&self, point: &Vector3<f32>) -> bool {
    const EPSILON: f32 = 1e-7;
    self.start.x - EPSILON <= point.x
      && self.start.y - EPSILON <= point.y
      && self.start.z - EPSILON <= point.z
      && self.end.x +EPSILON >= point.x
      && self.end.y + EPSILON >= point.y
      && self.end.z + EPSILON >= point.z
  }

I'm trying to figure out what's the easiest way for the user to use the library, if we use a monolithic library we need to set feature flags, but they can become quickly a mess, while in the other hand we can have different crates gaiku-baker-voxel, gaiku_file_gox, etc so will be cleaner what are you using, but you will end up having a lot of small crates.

In both cases the idea is to reduce the sub dependencies used by the final user, by only including what they really need, for gaiku-common will be no option but use feature flags, but maybe we can move the Texture, Chunk and Mesh implementations into another crate gaiku-common-impls (?)

Also other issue, is better to use underscores instead of dash, for the sake of consistency when declaring the deps in the Cargo.toml and importing them?

Althouth not exactly an issue it was unexpected. I was generating a random terrian using the noise crate, baking it in gaiku (with colors since I plan added random colors too) and rendering it in amethyst. For a long time I was not seeing anything and was surprised. Until I realized that the default color of the goxel is transparent

Would it be more intuitive to the user if this were white.

There's an issue that I spotted from the beginning but never bother to fix, and it's that all gox files are rotated, so right now they need a monkey patch to show correctly in the game engines or when exporting.

Hello again.

I have been getting back into my volume based rendering in rust and wanted to discuss some of the research with you.

Bakers

I have been looking at other surfacing algorithms and some of which I think we can implement into the bakers.

• Marching Tetrahedra
  • Similar to marching cubes but meshes are always manifold
  • Uses about 4x the number of verticies
• Transvoxel
  • This generates smooth meshes with LOD so that further aways vertices are further apart
  • This might be nice to add for non-block like terrain
• Dual marching cubes
  • Like marching cubes but creates fewer vertices on the planes then at the corners

Links:

• voxel tools go code for a similar project to this (includes transvoxel)
• smooth terrain blog blog post on making smooth terrain from volume data (includes comparison of different surfacing methods)
• voxel gfx Page that explains how to implement dual marching cubes as well as other aspects like trilinear shaders and octtrees for the LOD

Chunk Trees

With regards to a tree structure to hold chunks the most interesting one I've seen is this one by voxel gfx it holds the chunks in an octtree where each level represents higher detail. This has the nice benefit of allowing LODS to page in and out

On a more general structure I think we could use a method like dual grid to help work out the neighbors in a chunk tree

Density

Currently the chunks are all integer values on a grid. But it might be more useful to represent them as densities on a grid. There are a few benefits to this:

• Early exit
  • A density map is meshed by finding the surface of an isovalue, if the density at a voxel is very far away from this isovalue we could assume that neighboring voxels are also likely to be far away from the isosurface and can be skipped.
• Interpolation
  • We can interpolate values off of the grid points, this could be useful for working out arbitary LOD levels from the same source data
• Gradients
  • We can work out gradients. This can be used for the normal calculations and can be used for more complex meshing algorithms like Dual Contours that require gradients.

Perhaps my rust foo is not up to par but I am having issues with the method

fn with_size(width: u16, height: u16, depth: u16) -> Self {
    unimplemented!();
}

I want to add a trait that implements the Chunkify trait rather than an struct that implements the trait so as to reduce repeated code.

However the Sizable trait requires a method that returns Self. But for a trait Self has an unknown size

  --> src/mechanics/chunkable.rs:31:58
   |
31 |     fn with_size(width: u16, height: u16, depth: u16) -> Self {
   |                                                          ^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `Sized` is not implemented for `(dyn Chunkable + 'static)`
   = note: the return type of a function must have a statically known size

I cannot implement the Sized trait as once implemented we lose access to &self required for the width etc

error[E0038]: the trait `SizedChunkable` cannot be made into an object
  --> src/mechanics/chunkable.rs:27:14
   |
27 |     fn width(&self) -> u16 {
   |              ^^^^^ `SizedChunkable` cannot be made into an object
   |
note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/refer
ence/items/traits.html#object-safety>
  --> src/mechanics/chunkable.rs:12:39
   |
12 | pub trait SizedChunkable: Chunkable + Sized {}
   |           --------------              ^^^^^ ...because it requires `Self: Sized`
   |           |
   |           this trait cannot be made into an object...

Could we seperate out the with_size method into its own trait AND for that trait implement the Sized trait for it like the Default trait does?

In my terrain I have some high res chunks. Sometimes when (voxel) baking these chunks it ends up looking very odd

I think perhaps it is the indexes but I am not sure. Any ideas before I go down the debugging rabbit hole?

It is consistent and for the same seed it will make the same odd chunk

So I have been expanding the traits integrating density into the chunk system. Time and time again the voxel baker is giving me issues.

Consider this input data which is generated from noise ranging from 0m to 3m

0 1 1 0
0 1 1 1
0 1 0 1
1 1 1 0

If I bake this in voxel I get

□■■□ 
□■■■
□■□■
■■■□

Now consider the coordinates of the vertices they range from 0m to 4m. But I defined data from 0m to 3m

Now consider what happens if a split the chunk up (for the chunk tree for example)

Part A defined using data 0m-1m

0 1
0 1
0 1
1 1

Part B defined using data from 1m-2m

1 1
1 1
1 0
1 1 

Part C defined using data from 2m-3m

1 0
1 1
0 1
1 0

If we generate voxels in chunks then stitch them back together they are now 6m wide!

The marching cubes baker does not have this issues as its for loop is a half open range

0<=range<end

I could of course rework my input to not overlap like this. But it makes it incosistent with how other bakers like marching cubes and other ones I want to implement work. It also makes density difficult to work with.

In the case of density we are not limited to the grid points. It is perfectly fine to make a voxel at 0.99999999 depending on the chosen resolution. In this case we must use half open limits because reworking input to not overlap would stop it from being possible. e.g.

Part A without overlap

0
0
0
1 

Part B without overlap

1
1
1
1 

Without including both ends in the input there is only one value in the x present so interpolation at for example x=0.999999 is impossible.

I apologies if this is a confusing issue.

In short I think maybe the voxel baker should bake up to but not including the last grid point.

I could implement another voxel baker (e.g. blocky) that works more inline with this half open range present in other bakers. I just wanted your opinion on the matter.

Some crates have their name seperated with - and others with _.

gaiku-3d

gaiku_amethyst

It would perhaps be clearer if this was all either - or _ rather than a mixture across the project

mostly copied form the discussion in #34

This is another issue with unnecessarily duplicated vertices which causes this artifact:

There are two verticies at this point:

It seems the deduplication step of the meshing algorithm is not tolerant enough

I think it is caused here, which I was thinking of when I wrote this part:

cx - sx * (1. + EPSILON),
cy - sy * (1. + EPSILON),
cz - sz * (1. + EPSILON),

• When checking for duplicates sx = 1e-5
• sx * (1. + EPSILON) = 1e-5*( 1+1e-5) = 1.00001e-05 which is 6sf so it is fine`
• cx is the coordinate center which could be anything lets say 123.0
• cx + 1.00001e-05 = 123.0 + 1.00001e-05 = 123.00001 Which is 8 sf too many sf for f32
• Truncating previous to 6sf we get 123.000 which is equivalent boundary size of 0.
• Which means if there is any rounding error in the coordinate it won't be treated as duplicate