Added AABB support

[UserAB1236872]

I added basic support for axis-aligned bounding boxes. I may go slightly further into other simple intersection tests (capsule, sphere, possibly convex hull), but I'm not turning this into a 3D physics package or anything -- you're not going to see bounding volume hierarchies or anything like that. Intersection tests are very useful even for pure graphical applications.

[der-antikeks]

Thats a good idea! How about a collider interface? Something in the way of:
http://play.golang.org/p/HVWATh3i9U
It could be extended to other bounding volumes when needed and I can also move my Sphere Intersections into this library.

[UserAB1236872]

A couple things I don't like about that interface:

1. It promises that it will return whether or not the shape is engulfed. This is generally more expensive than checking collision (except for rays and spheres) I'd prefer Collides and Engulfs to be separate checks.
2. I think for IntersectsRay I'd prefer to still return tmin and tmax, knowing the entry and exit points (or at least the entry point) is often fairly important.

Speaking of Rays, whether at the function or struct level, we need to some to allow precomputed inverse directions to be used. Maybe something like this?

[dmitshur]

I may go slightly further into other simple intersection tests (capsule, sphere, possibly convex hull), but I'm not turning this into a 3D physics package or anything -- you're not going to see bounding volume hierarchies or anything like that. Intersection tests are very useful even for pure graphical applications.

It seems we're hitting the limits of what this package can do before its scope is "too big." Convex hull and other intersections test are incredibly useful, but I see them living in a higher level package.

Ideally, I think the best way to organize this would be:

• go-gl/mathgl - low level math primitives, like Vec2, Vec3, matrices, UnProject, etc.
• another/library - imports go-gl/mathgl and builds higher level algorithms on top, like intersection tests, bounding boxes, distances, containment, etc.
• potentially a/physics/library - imports go-gl/mathgl and builds 3D physics

The benefit of that approach is that it would keep each library smaller in scope, which means it's easier to maintain and can be higher quality. It allows people to import only what they need.

It also lets you add any kind of useful high level algorithm that fewer apps will need, but can be incredibly useful.

I don't really see disadvantages in splitting AABB/intersection tests away from the low level Vec2/Vec3 types into separate packages. If you go get the/higher/level/package that imports go-gl/mathgl, go get downloads both, so it's not a problem.

I would recommend you try to limit the scope of go-gl/mathgl as early as possible, and move the higher level algorithms that use mgl32.Vec2 or mgl64.Vec3 into another package.

Back when I was using C++ as my primary language, my all time favorite library was http://www.geometrictools.com/LibMathematics/LibMathematics.html, as it had algorithms for all kinds of distance and intersection tests (between 2D, 3D lines, rectangles, spheres, OBBs, you name it). I would love it if one day all those algorithms are available as a native Go package.

Conclusion

IMO, I think it's best to try to limit the scope of go-gl/mathgl to be as small as possible. Its goal should be to provide the Vec2/Vec3/Vec4, Matrix, etc. primitives that all other math/physics algorithm packages can use, so that they're compatible.

It would be a shame if some higher level packages use mgl32.Vec3 and some others use slightlydifferent.Vector3.

[UserAB1236872]

I see your point. To be totally honest, I was cribbing the initial method set from the linear algebra subpackage of Bullet (though I was gonna go a little tiny bit farther and add a couple more primitives than they have in the naked linalg package) -- I was planning on stopping at collision primitives; I had plans to add higher level stuff to mathgl, but under different package headers (mathgl/whatever32 and such).

I haven't decided if making a separate repository or doing the subfolder thing is better -- I suppose go get gets the entire repository regardless so maybe an entirely separate one would be better.

[UserAB1236872]

I essentially had one less degree of separation than you --

go-gl/mathgl/* Basic math and primatives
a/hypothetical/physics/package imports mathgl

I see the utility in that extra degree of separation, but I'm not 100% on the exact point it should happen. (Though I would argue that at the very least, RENDERING primatives should be in the package scope, since it matches gluCylinder and the like).

[dmitshur]

I was planning on stopping at collision primitives

I don't want you to stop! :) But it's best to keep the higher level things separate, so they don't reduce the value of the lower level VecN primitives. I want there to be one Go de-facto standard to import for VecN types, and that's easiest to do when that package is as small as possible (in order to cater to as many people as possible).

One other idea would be to keep the scope of mathgl/mgl* as is, but extract the lowest level types and their methods in a separate, smaller package. However, the problem with that approach is that users will then need to import both mathgl/mgl* AND lowlevel/* and they'll be forced to use different package names for the two (i.e., var float32 maxScale = mgl32.ExtractMaxScale(mgl32lowlevel.Mat4), which seems pretty bad. So I think this idea falls out.

[dmitshur]

Hah, and I've just discovered exactly what I was afraid of:

https://github.com/fzipp/geom

Via github.com/errcw/glow/examples/cube. (/cc @errcw)

Now there are some incompatible Vec2/Vec3 types, that, as far as I can imagine, probably try to solve the same problem.

It doesn't seem to have a lot of importers, but godoc is not a very representative measure of importers. FWIW, mathgl doesn't have a lot of importers on godoc either.

[UserAB1236872]

Well, I don't think we'll avoid packages that do the same thing, there are any number of 3D math packages in C and C++ (partially due to the great degree of NIH syndrome many game developers have).

That said, we could consider a hypothetical 2.0 release with more package fragmentation. I'll open another issue for that

[dmitshur]

FWIW, that cube example has started using mathgl as of errcw/glow@941c1cb.