Support for alternative normalized device coordinates

[filnet]

Hi,

As it been considered to support alternative normalized device coordinates for Orthographic3 and Perspective3 ? Currently both follow the OpenGL convention so are not usable in other situations (Vulkan for instance).

I am willing to work on it if it is desired to have that in nalgebra.

I can think of two approaches:

• have separate structures in separate pathes within the crate
• use generics and enums

[sebcrozet]

Hi! Yes, that would be a great contribution. Note that most of the variants of projections are already implemented in nalgebra-glm, so maybe some code can be taken from there to be integrated to nalgebra.

Regarding what approach is best, I am not sure. Maybe using generics that allow the user to select a specific variant would allow easier code reuse internally?

[filnet]

Ok. Cool. Will see what I can do.

PS : I meant "generics", not "templates".

[filnet]

There's also ext::matrix_clip_space.rs.

[filnet]

I hit a snag that currently prevents making Geometry3 generic over NDCs without making breaking code changes. It has to do with default type parameters for generics and some limitations in their current form. The limitations are addressed by RFC 0213-defaulted-type-params but it is currently stalled. The RFC has links to the tracking issue and the PR.

Anyways, since I am not affected by the breaking change, I went ahead and created a PR with some initial code changes. It is very basic but underlines the proposed structural changes. Please consider all names as place holders... This will hopefully foster a discussion on the design choices, naming and all.

The PR has some comments about design decisions and other topics. The PR also shows what the breaking change looks like and mentions a potential solution (that I dislike). See cg.rs.

Note that if a function is specialized, all other specialization have to be provided. It is not possible to keep a base implementation in the "base" struct. This is not really a problem in Perspective3...

Another more problematic issue is that a "base" function cannot call a specialized function. For instance new() needs to be specialized too because it calls set_fovy() and other specialized functions.

[filnet]

Note sure it is 100% related to defaulted type params but things are moving in this space: https://lcnr.de/blog/generic-const-expressions/

[stefnotch]

Until this gets fixed, it might be nice to update the documentation to point out that the perspective matrices follow the OpenGL convention https://docs.rs/nalgebra/latest/nalgebra/geometry/struct.Perspective3.html