don't forget to file that issue
Whoops, thanks for the reminder! This is now issue #90.
assembly module
During our meeting, we decided that cleaning up the forwarded project_to_normalized implementations will best be done in a dedicated pull request that encapsulates element representation data…
My first attempt to avoid forwarding the project_to_normalized implementations was:
- Make
project_to_normalizeda method of a newengine::EngineElementtrait. - Make `engine::EngineEleme…
I am happy with the names but it seems cumbersome that there are methods project_XXX_to_normalized and then two boilerplate implementations of project_to_normalized that just forward to the…
The branch is out-of-date. I would just click "update branch by rebase" but I am not sure if you want me rebasing your branches, so please bring it up-to-date as you see fit (and let me know if…
I've looked at the renaming commit again and I still think it's fine, so let me know what you think!
I guess this PR is working as is, but it just seems like a roundabout way to deal with colors... it's a bit hard for me to imagine that the ultimate version of the software will use this…
I just pushed a commit with better names (54b34e0582). My look-over before pushing was a bit cursory; I'll look at it harder later today.
How about something like proj_to_normalized, to communicate that we're projecting the given representation vector to the normalized configuration variety for the given element type?
So I…
Any reason you didn't just make colors have an alpha channel everywhere […]?
I was thinking that when we add a user-facing opacity setting, we'll also need to figure out how it interacts…
In my mind, an element is represented by a line through the origin in \mathbb{R}^{4,1}, so choosing a favored representative is equivalent to choosing a particular scaling. That's why I used the…