Future of nalgebra and math in Amethyst

(Erlend Sogge Heggen) #1

Continuing the discussion from:

As there are recurring murmurings about nalgebra, I wanna get a dedicated discussion going so we can move forward on this in an intentional manner.

I think @jaynus put it nicely :point_up_2:, nalgebra is just a different type of library from what we need most of the time.

The move to nalgebra (which I was a strong proponent of) was chiefly motivated by the fact that it comes with nphysics and is part of the very well managed rustsim project, courtesy of the excellent Seb.

But judging by the amount of times I’m hearing people run into nalgebra walls, it’s high time we started discussing what an alternative state of math in Amethyst might look like.

Here’s some open pondering anyone’s free to address:

Is it time to reconsider Mint :thinking:


We don’t want to lose nphysics integration, but we’d prefer not to use nalgebra for just about anything other than physics. Mint seems to offer a solution to that conundrum.

Ultraviolet looks great.

Made by the awesome @termhn, long time member of Amethyst. Used in path tracing renderer rayn.

Could it be well suited to become the standard math library for Amethyst?

3 Likes
(Khionu Sybiern) #2

Physics are a bit too important for our standard math library to not have a compatible physics library. If we can somehow have a model where physics is calculated separately (as high demands on physics can necessitate) using nphysics without imposing nalgebra as the standard, I think that would be most ideal. That said, I couldn’t be sure about whether having two separate math crates like this would be acceptable.

(Kel) #3

Without immediately getting into the discussion with a post on the topic, off the top of my head it’d probably be fine to have separate math libraries for the physics library and game engine in the nphysics case, since the only interoperability needed is the synchronization of poses, which are just translation/rotation data. So if the target math type can implement the following trait

pub trait Pose<N: RealField>: Component + Send + Sync {
    fn sync(&mut self, pose: &Isometry<N>);
}

That math type is then integrated with nphysics. This is currently conveniently done for amethyst with

impl Pose<f32> for amethyst::core::Transform {
    fn sync(&mut self, pose: &Isometry<N>) {
        *self.isometry_mut() = pose;
    }
}

Which really just boils down to a nice way to write that you’re copying a bunch of floats around so this would still work fine for Pose types that don’t contain an nalgebra Isometry type proper, but would just be a little more verbose.

2 Likes
Mechanism to sub-dispatch group of systems
(Gray Olson) #4

ultraviolet is relatively close to being usable in Amethyst. There’s a few more things that would probably need to be added from a functionality standpoint (basically, #1 #3 and #4 issues on the issue tracker), and then there’s the problem of testing. Since it’s currently just my pet project, I only have tests on very few things, but this would obviously need to be improved.

1 Like
(Tatsuyuki Ishi) #5

Since it was raised in Discord: how does https://github.com/yoanlcq/vek compare?

(Zicklag) #6

I’m in agreement that it would be good if we could keep nalgebra in the physics realm and use something else for the rest of Amethyst. The math library and how easy it is to use will be a big deal for anybody writing 3D games in Amethyst.

Also, unless nalgebra was completely integrated with the Amethyst transform system such that it actually used the ECS for storage, aren’t we copying a bunch of floats anyway to get the nalgebra values into the Amethyst transform components? That would mean that it isn’t costing us any extra performance to use a different library, especially when the more specific libraries for games and graphics can be more optimized because they are more specific.

(Gray Olson) #7

Vek is cool. It was my preferred linalg lib for ‘getting shit done’ before I made my own ;p I’ve stolen some of the things I like about it for ultraviolet, like map / apply functions on vectors.

Unfortunately I don’t think it’s a great fit for Amethyst. Its performance is not very good currently (as stated by the author, not much if any effort has been put into optimizing that part of the lib yet), even considered next to nalgebra, and it doesn’t seem as though there is anything that would make this change soon without Amethyst project stepping in to do so.

Also, I think the repr_c vs repr_simd separation is not very good fit for amethyst as the repr_simd types basically just do what glam does, but not as well.

Speaking of which, glam is the other lib I’d look at seriously for consideration in amethyst personally. One relatively significant endorsement is that Embark is now using glam for their rust engine internally.

2 Likes
(Grey) #8

I’m just a transplant from the robotics community with budding interest in using Amethyst for game development, but this is a topic that’s very relevant for me, so I hope it’s okay for me to butt in a little.

I haven’t looked at glam besides a superficial glance at the README, but I found the section about the coordinate system very alarming.

Maybe the graphics/game development community has different conventions from what I’m used to from the robotics and physics communities, but a left-handed coordinate system would leave my head absolutely spinning. I’d end up with countless bugs if I tried to use such a convention, especially in 3D space.

But maybe this is just the normal convention in gaming and I’m going to have to transition to it if I want to play around in the field?

(Erlend Sogge Heggen) #9

If Ultraviolet is on its way to feature parity with glam then I’d rank Ultraviolet higher just because it’s made by an Amethyst member, so it has a higher Trust & Communication score so to speak :slight_smile:

If there’s a way to join forces with some of the other math maintainers that would of course be preferable, but it seems this field is too fraught with strong personal preferences for that to happen. (That said, glam also happens to be used in a path tracer by its maintainer so maybe there’s enough overlapping interest here that we could get a dialogue going).

(Cameron Hart) #10

Hi there, @erlend_sh mentioned that glam was being discussed here and invited me to join in.

I should probably remove that from the README as it greatly overstates the situation and I’ve seen similar concerns mentioned elsewhere. glam is by and large co-ordinate system agnostic. The only function that vaguely implies a coordinate system is from_rotation_ypr, where yaw is considered to be rotation around y, pitch around z and roll around x. Using a different co-ordinate system yaw, pitch and roll might be around different axes. That’s the only part of glam that has any notion of a co-ordinate system because I didn’t want to support all possible permutations of Euler angles.

In any case, thanks for considering glam as a possible future math library for Amethyst. I have no idea how suitable glam is in it’s current state for use in Amethyst, but I’d be happy to answer any questions and discuss any features Amethyst might require if that’s the direction you wanted to go in.

1 Like
(Grey) #11

Thanks for addressing my concern, @bitshifter! After about an hour of deep contemplation and waving both of my hands around in the air, I’m reasonably satisfied with concluding that there wouldn’t be a mathematical difference between left-handed and right-handed coordinates; it’ll just be a matter of how inputs and outputs are interpreted by the user of the linear algebra library.

In terms of Euler angles, I really like the Eigen::MatrixBase::eulerAngles(~) function of the Eigen C++ library which lets you specify which representation you’d like. Maybe someone could contribute a similar feature to glam at some point. But I’m getting off topic now, so I’ll leave the matter at that.

1 Like
(Alec Thilenius) #12

Another consideration: ergonomic types will be much more important for the new transform system.

Using the math lib types directly for the new legion_transform was very elegant. I really liked the clean separation of concerns between ‘the things linear algebra math libraries should do’ with the 'how do we put those together to create transform spaces and hierarchies`. All components are just nalgebra types in legion_transform.

I’ve already expressed concerns with the fact that the nalgebra type (for a game <engine> developer) are hard to work with, made even harder by the fact that RLS can’t seem to make heads or tails of the templating and thus never offers auto-complete suggestions.

2 Likes
#13

I’m quite late to this conversation, but my experience has been:

  • nalgebra_glm - it’s really great most of the time, except when the type system gets in the way
  • glam has worked pretty well for me
  • My ideal math library would be a direct port of https://github.com/microsoft/DirectXMath.
    • It’s familiar to many professional developers
    • It’s mature and battle tested
    • It has extensive SIMD support (x86_64 and arm)
    • It is appropriately low-level, directly exposing SIMD. (They have two layers… one that looks like glm/glam, and another one that’s a little lower level that keeps SIMD a bit more exposed… which can be beneficial in some cases.)
    • It’s likely to be maintained long term by Microsoft. So as new instruction sets are added, it’s likely they would implement support for them.
    • Unfortunately I haven’t seen a good port of this yet :confused:
(Gray Olson) #14

As an update: I’ve just released ultraviolet 0.4. With this release, all, or at least most of, the important things that Amethyst would need have been implemented (I’m sure there’s a few things missing that I just haven’t thought of ;p). However, it’s definitely in need of a testing harness of some sort.

3 Likes