Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The way of cgmath #419

Open
kvark opened this issue Jun 7, 2017 · 10 comments
Open

The way of cgmath #419

kvark opened this issue Jun 7, 2017 · 10 comments
Labels

Comments

@kvark
Copy link
Collaborator

kvark commented Jun 7, 2017

I believe that cgmath went in the wrong direction lately. It got more traits to consider that are not as much graphics related as they are purely mathematical (EuclideanSpace, InnerSpace, etc). I don't think that's the way cgmath needs to evolve itself - we already got nalgebra as a highly abstracted (non graphics-focused) library. Instead, I'd like to see cgmath being simpler and having next to no traits.

cc @brendanzab

@kvark kvark added the question label Jun 7, 2017
@msiglreith
Copy link

I actually like these traits as they allow to abstract over functionality and don't restrict yourself to either 2d or 3d. For real-time rendering isn't needed very often imo, but for e.g physically based animations, it's quite nice.

With 'simpler' it's meant 'simpler for users' or implementation side?

@kvark
Copy link
Collaborator Author

kvark commented Jun 7, 2017

@msiglreith Good point. It appears that 2d/3d abstraction would be sacrificed if theses traits are removed. What do you mean by "physically based animations" btw?

With 'simpler' it's meant 'simpler for users' or implementation side?

Simpler for documentation, no need to include a magical prelude, and the implementation may become more readable, even if not with less code.

@msiglreith
Copy link

What do you mean by "physically based animations" btw?

Mostly rigid/soft-body physics and fluid dynamics (in the computer graphics domain).
E.g having to write a SPH implementation for 2d and 3d at the same time due to the trait abstraction saves a lot of time (mainly debugging).

@brendanzab
Copy link
Collaborator

Thanks for the issue, and good points raised! Sorry for the lack of response - I have been on holiday and just got back today!

@brendanzab
Copy link
Collaborator

Personally I'm more a fan of using mathematical structures as a basis for traits, hence why I pushed it in cgmath. It has been really nice to see @sebcrozet following this lead in nalgebra, and pushing it much further than I did. That said, it might be more helpful for the community to have a greater point of difference between the two libraries, so perhaps it might make sense to unwind some of these changes in cgmath. 🤔

I would like to hear from those who are in favour of the mathematical traits, and whether nalgebra might be a viable alternative for them. I would also have to consider switching to nalgebra, and transferring ownership of cgmath to another maintainer, or the community. I don't rush into anything just yet. I hope that makes sense!

@kvark
Copy link
Collaborator Author

kvark commented Jul 5, 2017

@brendanzab it's almost like your paragraphs should be moved out to separate comments, given they induce entirely opposite emotions to many of us.

@LaylBongers
Copy link

I personally think cgmath strikes a good balance, where nalgebra goes to a far extreme that makes it harder to use in projects. I always feel like the best approach isn't in going to one of two extremes but finding a practical middleground.

@brendanzab
Copy link
Collaborator

brendanzab commented Jul 13, 2017

Yeah, that's what I was kind of aiming for. Perhaps we could try implementing some method aliases that forward to the trait versions. Then people could use the direct methods initially, then level up to use the more generic traits if they need them.

@MaikKlein
Copy link
Contributor

Something like this? I think that would be the best approach. (At least for the fundamental operations)

@brendanzab
Copy link
Collaborator

Yup - that's the one!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants