Roadmap to 1.0

[yoanlcq]

Pre-requisites for 1.0

• Fix all TODOs and FIXMEs. Fix as many XXXs as possible.
• All doc is re-read (especially the FAQ) to ensure it reflects the current situation well.
• Reference material such as "How we do SIMD at insomniac Games", illustrating how it applies to vek;
• Macros are actually documented (even internally).
• Enable all possible targets on Travis CI;
• Assembly-check all the things!
• Write some benchmarks.
• Make an annoucement and get feedback from the wider Rust community before going 1.0.

Awaiting triage

• Make vectors properly implement AsRef and AsMut to all other kinds of vectors;
  • ... as long as the target dimension is greater or equal, and it's not a C -> SIMD conversion (because of alignment requirements).
• More From conversions from vectors to other kinds of vectors;
• Re-provide the fix, fpa and num-bigint optional dependencies.
  The point is to make their types implement most of vek::ops traits;

Docs and publicity

• Make a cool logo! (I'm already on it.)

Features

• impl FromStr for vectors and matrices!
  • With a special case for Rgb and Rgba;
• from_html_hex(s: &str) for Rgb and Rgba;
• Quaternions:
  • look_at() rotation (See Unity ?);
• Matrices:
  • orthonormalized (for Mat4);
  • Add 3D shearing.
  • Add symmetry transforms.
  • Add decompose() (steal from GLM) (and make it a conversion into Transform!)
  • Add scale_from_point and rotate_about_point (I've seen these somewhere, but can't recall exactly)
  • is_diagonal_matrix()
  • is_symmetric()
  • FromStr
• Add Euler Angles ?
  • I'm not sure, because they suck, and nobody agrees on the order in which
    rotations are applied. Some say X,Y,Z, others say Z,Y,X.
    I'd rather leave this to users who know better what they want.
    The only use case I can think of is GUIs, and it's as misguided as using degrees IMO.
    Fix the GUI, not the intermediary representation.
• Free functions.
  This would require pulling new traits out of existing functionality.
  • dot()
  • hadd()
  • cross()
  • distance()
  • normalize()
  • reflect()
  • refract()
  • face_forward()
  • angle_between()
  • transpose()
  • invert() (matrix, not color vector)
    Note that there are no free functions for Lerp, Slerp, etc.
    It's enough to just write Lerp::lerp(..). Less pain for us to maintain, but I might change my mind.
• Consider turning the ops module into a vek-ops crate (Like num did with num-traits)
• Consider experimenting with a vek-derive crate for deriving Lerp and stuff;

Soft fixes

• Make sure to fullfill the SIMD efficiency promise.
  • Use platform-intrinsics for operations on repr(simd) vectors, including shuffles.
  • transposed_sse() for Mat4<f32> (based on _MM_TRANSPOSE4_PS());
  • transposed_sse2() for Mat4<i32>
  • dot_sse4_1() for Vec4<f32>
  • load/store_nontemporal() for Vec4<f32> and Vec4<i32>
    (!! needs fencing! So there should be associated fence functions! !!)
  • Many others ??? (cmpgt, average, etc!!)

[zesterer]

How goes progress on this? I'm looking to potentially use vek in a project I'm working on.

[yoanlcq]

I've been using vek in several personal projects since its latest release and I've found it to be already quite feature-complete and usable (by projects, I mean a few small libraries and a 3D game using OpenGL).

This issue mostly lists optimizations and enhancements I'd like to see to call vek "100% finished" but I'm currently spending my time on other projects, not only to battle-test it, but also because it has the features I think most projects need.

Obviously I suggest looking at the docs and the Wiki (and eventually the source) to see if everything you need is there. Otherwise, feel free to let me know which precise features you'd like to see and I might focus on these. :)

[zesterer]

I'm happy to act as co-maintainer, if necessary. I've so far been developing my own solution, coord. vek seems virtually identical to how I imagined a final version of coord, so to me it makes sense to focus my efforts here instead.

[yoanlcq]

I've taken a look and it indeed looks like coord's goals are similar to vek. I you encounter problem or miss features when moving to vek, you're always welcome to file issues or submit Pull Requests (in which case you'll be listed in the README, Cargo.toml and stuff as a contributor! :) ).

I don't mind directly adding you as a contributor of this repo, but I prefer Pull Requests since they allow me to check that everything is 100% fine, and stir discussion if it's not.

From what I've seen vek appears to have the features you're looking for; in fact, this "1.0 roadmap" really is more like gold-plating and doesn't imply vek is "unfinished", if this was a concern.
I would say, we're at a "practical 1.0" wherease this list aims for "public 1.0".

(Part of me feels kinda bad that another crate could be "abandoned" in favor of mine. But it's always up to you :) )

[zesterer]

I you encounter problem or miss features when moving to vek, you're always welcome to file issues or submit Pull Requests

Thanks. That gives me a lot of peace of mind.

I don't mind directly adding you as a contributor of this repo, but I prefer Pull Requests since they allow me to check that everything is 100% fine, and stir discussion if it's not.

That's perfectly reasonable: I'd do the same.

(Part of me feels kinda bad that another crate could be "abandoned" in favor of mine. But it's always up to you :) )

I'd rather avoid code duplication by improving an existing codebase. vek clearly outlives coord by quite some time, so I'm more than happy to yield to it. If I'd known that vek existed, I wouldn't have created coord.