Skip to content

Instantly share code, notes, and snippets.

@japhb
Created January 7, 2014 04:18
Show Gist options
  • Save japhb/8294561 to your computer and use it in GitHub Desktop.
Save japhb/8294561 to your computer and use it in GitHub Desktop.
Proposal: Performance-oriented Perl 6 3D math lib

One Perl 6 3D Math Lib to Rule Them All

There are currently several different 3D-related math libraries for Perl6: Math::Vector, Math::Quaternion, etc. They don't interoperate smoothly, have different API designs, and aren't designed with efficiency/performance as a primary goal.

I propose we create a new 3D/graphics-oriented math library with the following design parameters.

Design Parameters

  • Build sugary syntax on top of efficient underlying implementation, allowing the library user to choose their tradeoff point
  • Default to (type system and mathematical) correctness
  • Offer a broad swath of the math operations needed for 3D/graphics work
    • General spatial object classes: Vectors, Rays, Matrices, Quaternions, homogenous coordinates, etc.
    • Operations specific to 3D work: ray reflection/refraction, transformation matrices, coordinate clipping, camera setup, etc.
  • Users needing more than the library provides ought to be able to improve upon the existing library, not be forced to write yet another library from scratch

Implementation Concepts

  • Core API reflects positional-style access; xyzw/rgba/rijk etc. coordinates are provided as convenience accessors
  • Underlying storage is positional as well (Array, Array[num], CArray, etc.)
  • Computations performed directly on positional storage values, not via accessors
  • Avoid object churn (allow explicit pre-allocated temporaries; provide mutating APIs as an option)
  • Work with the optimizer as much as possible (make sure operations are inlineable, etc.)
@colomon
Copy link

colomon commented Jan 7, 2014

If you are really worried about performance, shouldn't this just be a wrapper around C/C++ code?

On a similar note, it might make sense to start from the perspective of "What types would be easiest to interface with OpenGL?"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment