Replies: 6 comments 7 replies
-
Thanks for posting this; I think it's worth discussing! Initial thoughts:
Agreed, this would be nice to have. We could add these to
By far the most serious limitation (but comes with an ergonomic and potentially compile-time cost). I would very much like this for managing coordinate systems, swapping between fixed point / f64 coordinates (see #1680), possibly maintaining distinct
I think this is mostly an anti-feature: we should be using a proper color crate for this, see #1797.
For bounding boxes, line segments and so on see: bevyengine/rfcs#12 I'm not sure I love the idea of outsourcing our geometric primitive types (there's a lot to profile and get right), but I could be convinced.
This is important, and could be improved upon.
This is also useful, and could be added. @bitshifter is quite active; I suspect we could contribute upstream to get most of these features: generic vectors (and some dereferencing pain) are the main arguments to consider migrating IMO. The other small consideration is that if we migrated to |
Beta Was this translation helpful? Give feedback.
-
While SIMD support is also described in the docs: https://docs.rs/glam/latest/glam/#simd
This is worth putting at the top of your list of grievances. Obligatory reference: Let's remove Quaternions from every 3D Engine |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm the author of
As already pointed out above by @parasyte this is not the case. My understanding of
This is a different approach to I also maintain mathbench which attempts to benchmark various Rust math crates and compares both scalar and wide variants. If you are interested recent bench results can be found in the here.
These could of course be added. No one has asked for them so far. I do not think that per element operations would perform well for SIMD types compared to more explicit methods but I can see how they could be convenient where an explicit method does not exist.
Generic types is definitely not a goal of
Probably not something I will add in the near term. Quaternions are still very commonly used. API wise rotors look quite similar to quaternions to me except there are additional concepts to learn about like bivectors. I appreciate the elegance of geometric algebra but I think I will wait and see if there is wider adoption in the industry before moving on that. |
Beta Was this translation helpful? Give feedback.
-
I'm here because I was missing some API from the euclid crate (specifically this one), considered maybe adding some and then realized that there were I really liked the coordinates tag used in euclid. e.g. pub type ProjectionMatrix = Transform3D<f32, WorldSpace, ScreenSpace>; which allows the compiler to check for you that you're applying the right transforms (ever forget to take the inverse of a matrix?). |
Beta Was this translation helpful? Give feedback.
-
My largest complaint is that the choice for If I were to pick a math library, it would most definitely be
It would be ideal if Transforms -> Global Transform -> MVP Matrix was done in The rendering engine and certain types (such as Mesh) could of course remain in There is zero performance loss from going to Also, there may be incentive to support double-precision rendering at some point, but that seems like it would be far, far off, and probably out of scope.
I think this is a bit orthogonal, and moving to |
Beta Was this translation helpful? Give feedback.
-
While using Bevy, I've been a little disappointed with the choice of
glam
for vector types. While it fulfills minimal criteria, it lacks a number of useful features that I've personally found are very useful in gamedev.Missing features (inexhaustive)
map
,fold
,reduce
, etc.)VecN<bool>
andVecN<VecM<T>>
crop up a lot in a number of algorithms and not being able to use them without abandoning the vector types entirely is quite the sharp edge)Rgb
/Rgba
Aabr
/Aabb
LineSegmentN
spirv
feature flag)RotorN
(rotors are often more ergonomic/easier to reason about than quaternions, and generalise to N-dimensional space)Proposed alternatives
The
vek
crate solves most of the problems I listed above, and the author is very receptive toward changes. As a little anecdotal testimony: we usevek
in Veloren and we've always found it to be pleasantly ergonomic, even for particularly complex cases.Beyond
vek
, there are a myriad of other crates. Of particular note arenalgebra
andultraviolet
, although both have their respective problems:nalgebra
's documentation is very difficult to navigating owing to its intense focus on type composition and this, in addition to its lack of useful utility methods, makes it a difficult crate to use in practical gamedev scenariosultraviolet
's API is inspired byvek
, so exhibits some of its API features (map
, for example) but its intense focus on performance and SIMD means that it drops a number of important features on the floor, such as generic typesPossible solution
I don't believe that there exists a single crate that solves all of the aforementioned issues, but I feel that, with a little work,
vek
is by far the closest towards covering these cases.RFC
I've opened this issue to initiate discussion, but I realise that this is potentially a large enough change that it would require an RFC in the future.
Beta Was this translation helpful? Give feedback.
All reactions