ublubu / shapes Goto Github PK

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

The inverse effective mass of a pair of objects along the constraint axis

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

NOTE: Can't make type family of kind #. (confirm?)

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

Lagrangian multiplier - the (signed) magnitude of the impulse
required to solve a constraint equation.

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

Hey there @ublubu! Are you still working on this project? Any idea how long before a hackage release (0.1 even).

See shapes/src/Physics/Engine/Main.hs line 54

• Opened on master
• Found on swizzle
• Closed on swizzle
• Closed on prim
• Closed on swizzle-noinline
• Closed on master

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

I'm guessing you already knew this as you mention in first in your reddit link but just doing a quick stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto" shows that Physics.Broadphase.Opt.Aabb.culledPairs.f is the biggest CPU cost center. It has two IntMap lookups which at first I thought may be the culprit but IM.lookup doesn't even show up in the prof file, and I've enabled library profiling. I'm not sure - I'd like to take a look at the generated core and see if I can make any sense of it. It could be that using a list is the culprit.

1. culling contacts
2. culling constraints (e.g. no friction constraint for mu = 0)

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

I've been following this project for a few months and I'm excited that there's a physics library that's not stuck in the IO, but there's a pretty severe lack of haddock documentation right now which is making it difficult to learn the library.

see lap, Geometry.overlap

see lap, Geometry.overlap

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

this one's for you, @schell

comment with your questions, so i know what to write about

a107266
aee20f2
ccf4946

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

set up one of those fancy buttons in the readme that says whether this project is broken

set some version bounds for the dependencies. i plan to just use the major versions of whatever i'm building with using stack.

Get a 6D velocity vector for a pair of objects.
Same as '_constrainedVel6'

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

pre-descZipVector, profiled 10 frames at 130ms
post-descZipVector, profiled 10 frames at 190ms
post-descZipVector-inline, profiled 10 frames at 130ms

why does pre-descZipVector run 100fps in the demo?

8e79bd2

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on hlint

There are lots of 2d physics engines out there and a couple already have Haskell bindings (box2d, chipmunk). These are both battle tested and proven technologies. I don’t think shapes can compete with them in a standard “technology pull” project environment (one where the tech is picked based on the needs of the project). Asking a game developer to write their game in Haskell is a hard sell. So what can Haskell do that other languages cannot?
Haskell can guarantee reproducible results through referential transparency. Shapes already does this to a certain extent - it’s pure, so one set of inputs should always give you the same output, but the implementation of some underlying floating point operations (1) are platform dependent! Simulations on different machines or different build targets may produce different results.
Would it be worth it to use the techniques outlined by Joachim Breitner (@nomeata) in section 5.1 of this paper to ensure deterministic simulation under all circumstances?

Pro

• Gives shapes and Haskell a reason to be used above all other tech stacks.
• I think this space is bigger and more fun than it seems at first.

Con

• Lots of work
• Will be slower at runtime

Fun to think about, none the less.

(1) - transcendental functions like exp, sin, cos, log, etc.

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

let things be bouncy

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

i can probably be more judicious with the inline pragmas

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

This would make using this library more discover-able.

In Physics.Engine.Class, makePhysicalObj takes a mass of (x, y). Why is the mass a vector? What does it represent?

https://github.com/ublubu/shapes/blob/master/shapes/src/Physics/Engine/Class.hs#L23

add INLINE pragmas, particularly in shapes-math and Utils.Utils

Using stackage nightly to build with ghc8 I found that shapes-math is erring with:

    /Users/schell/Code/shapes/shapes-math/src/Shapes/Linear/Template.hs:43:20: error:
        • Data constructor not in scope: NotStrict
        • Perhaps you meant variable ‘notStrict’ (imported from Language.Haskell.TH)

    /Users/schell/Code/shapes/shapes-math/src/Shapes/Linear/Template.hs:54:34: error:
        • Couldn't match expected type ‘Maybe Kind’
                      with actual type ‘[Con]’
        • In the fourth argument of ‘DataD’, namely
            ‘[NormalC vectorN (replicate dim constrArg)]’
          In the first argument of ‘(:)’, namely
            ‘DataD
               [] vectorN [] [NormalC vectorN (replicate dim constrArg)] []’
          In the expression:
            DataD [] vectorN [] [NormalC vectorN (replicate dim constrArg)] []
            : impls

    /Users/schell/Code/shapes/shapes-math/src/Shapes/Linear/Template.hs:54:83: error:
        • Couldn't match type ‘Dec’ with ‘Cxt -> Dec’
          Expected type: [Cxt -> Dec]
            Actual type: [Dec]
        • In the second argument of ‘(:)’, namely ‘impls’
          In the expression:
            DataD [] vectorN [] [NormalC vectorN (replicate dim constrArg)] []
            : impls
          In an equation for ‘decs’:
              decs
                = DataD
                    [] vectorN [] [NormalC vectorN (replicate dim constrArg)] []
                  : impls

    /Users/schell/Code/shapes/shapes-math/src/Shapes/Linear/Template.hs:55:3: error:
        • Couldn't match type ‘Cxt -> Dec’ with ‘Dec’
          Expected type: Q [Dec]
            Actual type: Q [Cxt -> Dec]
        • In a stmt of a 'do' block: return decs
          In the expression:
            do { let vectorN = makeVectorN dim
                     constrArg = ...
                     ....;
                 impls <- concat <$> mapM (\ f -> f vectorN vi dim) definers;
                 let decs = DataD ... vectorN ... ... ... : impls;
                 return decs }
          In an equation for ‘makeVectorType’:
              makeVectorType vi@(ValueInfo {..}) dim
                = do { let vectorN = ...
                           ....;
                       impls <- concat <$> mapM (\ f -> f vectorN vi dim) definers;
                       let decs = ...;
                       .... }

It seems template-haskell 2.11 has some breaking changes. What is the TH mostly used for in shapes-math? Maybe there's a non-TH way to accomplish this?

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

I know shapes is 2d and that 3d isn't on the roadmap, but how much more work is adding a separate 3d module? Maybe only using boxes or spheres?

Flatten a 'Contact' into 'Contact''s.

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on hlint

split contactsolution cache into impulse cache (copied between frames) and constraint cache (single frame)

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

instance (Epsilon a, Floating a, Ord a) => WorldTransformable (ConvexHull a) a where
transform t = flip transformHull (transform t)
untransform t = flip transformHull (untransform t)

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

• Found on swizzle
• Found on prim
• Found on swizzle-noinline
• Found on master

dynamics may be updated many times during the constraint-solving steps of a frame.

shape information is only updated after all the constraint-solving is done.

it may be more efficient to keep separate data structures for each kind of state (and user data also).

now that there's only one implementation of the physics engine, there isn't really a need for these classes.

arguments in favor of keeping the typeclasses:

• documents the "API" of an actual "physics engine"
• adding engine variants in the future

culledKeys are in order
change keyedContacts so they are also in order (make keyed contacts flippable and sort by feature?)

zip keyedContacts with old cache vector to create new cache vector

• discard unmatched cache entries
• solve contact to populate missing cache entries

^ new cache vector is dense; first contacts get an extra solver iteration - less jittery/bouncy