OK. I understand. The argument is that LookAt and Perspective are outside
the scope of something that needs the maintenance and stewardship of the Go
team. I think that is an acceptable answer. I suppose my expectations were
not aligned.

Though, it seems to me that if one of the example programs needs this
functionality and it should not be part of the exported
golang.org/x/mobile/... APIs then it should be vendored from another
3D-math library or implemented in an internal library. I don't think
letting things stagnate as they are is helping anyone.

And, maybe I'm missing something but it doesn't look like any exported APIs
in golang.org/x/mobile/... expose f32 types directly (other than the f32
package itself). It seems like the entire package could be deleted today
and an internal/vendored package used until the appropriate arithmetic
operations are added to x/image/math/f32.

Is there a reason not to do that?
On Thursday, March 31, 2016 at 2:49:13 AM UTC-7, Nigel Tao wrote:

On Thu, Mar 31, 2016 at 6:46 PM, Bryan Matsuo <bryan....@gmail.com
<javascript:>> wrote:
It seems to me that two non-trivial graphics-specific functions in f32,
Mat4.Perspective() and Mat4.LookAt(), were implemented expecting
column-major order (possibly from a corresponding implementation in C or
some literature?).
IIRC, crawshaw wrote those Go functions. Perhaps he can remember their
providence. I have a vague memory that some example (3-D viewer??)
program used it in the past, but I can't remember the details.

Still, I'd rather just have the one consistent order everywhere, if

Furthermore, because of these two functions Perspective and LookAt can the
package really be fully deprecated?
Note that the "exp" in "x/mobile/exp/f32" stands for experimental. Its
API is far from set in stone.

You seem to be discussing these functions specifically; and you are saying
that image/math/f32 is not their home.
I'm open to being convinced otherwise, but my instinct is that
x/image/math/f32 is not their home. It is easier to add API later than
remove it, so I'd rather err on the side of too little API for now.
Matrix multiplication seems common enough, across a variety of
applications, to warrant being inside the x/image/math/f32 package.
The case for dedicated Perspective or LookAt methods is less obvious.

If some 3-D graphics package, or program, wants to be able to set up a
camera via LookAt, it seems plausible to have that function live
inside that package, or in package main. It's not like a f32.Mat4 has
non-exported state that only in-package code can access. If its code
must be shared, it could live inside some f32util package, rather than
having to be inside x/image/math/f32 per se.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 17 | next ›
Discussion Overview
groupgolang-dev @
postedMar 29, '16 at 3:30p
activeMar 31, '16 at 12:58p



site design / logo © 2021 Grokbase