Cube generates a cube centered at the origin with sides of length two. Just as Sphere generates a unit sphere, maybe Cube should generate a unit cube with sides of length one?

Could you please update the crates.io version of this crate? Looks like it hasn't been updated in 3 years.

The primitives right now just produce a primitive that is close to a unit vector. The original idea was that people would scale the primitives using the .vertex() trait. There are a few cases where I don't think this is satisfactory. The cone primitive for example has different normals based on these values, so for the sake of our uses we should add them.

Considering #25 and #26 to generate more vertex data, we may end up with too much (partially redundant) code if we want the generators to support various combinations like vertex + normal, vertex, vertex + tex-coords.

We might want to consider a single vertex format to be used by all generators, potentially also covering #27. The user should still be able to map the vertex to its own format and drop some of the generated data.

The main problem I see here is the complexity of shared vertex generation. For example, a cube would no longer be able to share any vertices, since each face has a different normal (unless we smooth normals over the cube, which doesn't make much sense).

The library needs some sort of testing. For example, we could compare the output of Iterator implementation for each generator versus SharedVertex + IndexedPolygon data.

We have used tuples because of the history problems with fixed sized arrays in rust. These days fixed sized arrays are much easier to work with, so we should look at migrating some of the types to use arrays.

See Quad and Triangle.

The crate name is off, but essentially this is the direct alternative to genmesh:
http://ncollide.org/rustdoc/ncollide_procedural/

It's used in kiss3d. Would be interesting to look inside and see what we can learn.

issue with obsolete syntax

$ cargo build
   Compiling genmesh v0.0.12
/home/chris/.cargo/registry/src/github.com-1ecc6299db9ec823/genmesh-0.0.12/src/sphere.rs:108:18: 108:22 error: obsolete syntax: `:`, `&mut:`, or `&:`
/home/chris/.cargo/registry/src/github.com-1ecc6299db9ec823/genmesh-0.0.12/src/sphere.rs:108         let f = |&: u: usize, v: usize| {
                                                                                                              ^~~~
note: rely on inference instead
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile `genmesh`.

Categories:

• As part of the mesh generators (sphere, plane, cube)
• Computed based on the vertices supplied (flat shading)
• Averaged based on the faces shared supplied

Heya, since most other gamedev related libraries are on nalgebra, I'd like to update this library to use that as well.

Another reason is that the current version on crates.io (0.6.2) depends on cgmath 0.16.1, which depends on rand v0.4.6. By swapping to nalgebra, at least for the amethyst game engine, we get to remove at least both the cgmath and rand crate compilations (there may be others, but I haven't done a thorough check).

I'm thinking in the future, if ultraviolet becomes the standard, we could put the relevant math library choice behind feature flags, though that's something in the future future.

Instead of generating duplicate vertices, one could generate indices and share vertices.

Most if not all of the generators in genmesh emit a set number of vertices on .vertices. Yet, this iterator does not implement ExactSizeIterator.

This can be unergonomic when working with crates that expect an iterator of a fixed length. For example, when you create a buffer in Vulkano and you want to fill it with values, it expects an ExactSizeIterator.

How to fix this

Vertices internally uses EmitVertices. The issue with this is that EmitVertices is not an Iterator, and thus the amount of vertices it will emit is not set.

The best way to fix this is likely to implement Vertices directly on every generator, and leave EmitVertices around for backwards compatibility.

Are you planning to add support for geometry used outside a realtime context?

Shouldn't it create only 8 vertices?

List of Meshes genmesh should be able to generate:

• Plane
• Cube
• SphereUV
• Sphere Icosahedron
• Torus #23
• Cone #48
• Cylinder #40
• Rust Logo

The library is almost without docs.

It's a nice object that can occlude itself and looks beautiful when rotating.

I need the smoothing to be configurable by a flag. Currently, normals of cylinder and sphere are smoothed.

As part of applying normal maps to generated meshes, it would be useful to have genmesh generate tangent vectors in addition to normal vectors for each vertex.

The recent rust breakage showed how genmesh could be a weak link of the ecosystem. gfx-rs breaks on it, glium does as well. We'd have to temporarily avoid using genmesh for the time of your absence. Perhaps, share some push access, or even move the repo under Gfx or PistonDevelopers?
Personally, I'd like to see gfx-rs/mesh_gen ;)