FAQ
Also, I'm sorry but I can't really comment on affine transformations
(skeletal animation) and optimizations in the GPU. I am still new to this
stuff. Though I'm not necessarily suggesting that the f32.Affine type needs
be changed. I'd be happy to hear other people comment on that, though.
On Tuesday, March 29, 2016 at 3:46:43 PM UTC-7, Bryan Matsuo wrote:

Thanks for the feedback.

I guess I might not have clarified the serialization situation enough.
AFAIK you are right about memory layout. [4][4]float32 should layout
identically to [16]float32. And if you do unsafe type conversions you can
turn either into the appropriate sized []byte for passing to
glctx.Uniform4fv, glctx.BindBuffer and OpenGL will copy this data into the
GPU (this is definitely how people in C and C++ do it). If that's really
what is **supposed** be done in Go, and it's guaranteed to work, then that
is OK by me and serialization isn't a concern. But if that is the case then
defining the serialization function, f32.Bytes, in the first place doesn't
really much sense, does it?

Related to this point, one thing I haven't had a definitive answer for in
my own mind is whether [16]float32 is guaranteed to contain the same bytes
as [16]C.float. Naively I would say, "yes they are the same," but from what
I've read elsewhere I'm actually not sure that is guaranteed.

In regards to multiplication order, yes, because Transpose(A * B) ==
Transpose(B) * Transpose(A) you can do work on column-major matrices using
row-major algorithms. But actually recommending that people transpose all
their matrices and reverse their matrix multiplication sounds quite
sadistic to me, truly. I really do think column-major should be used, even
if [4][4]float32 is truly the desired type signature. It sounds like we
mostly agree there, though.

But if using a [4][4]float matrix with column-major order things are
somewhat confusing because matrix literals will look like they are being
defined in row-major when they are not. I honestly think all access
problems on flat arrays could be solved with adequate methods for indexing
and modifying matrices index values.

// Get returns the value in row i and column j of m.

func (m *Mat4) Get(i, j int) float32

// Set stores f in row i of column j in m.

func (m *Mat4) Set(i, j int, f float32)

// Cols sets the columns of m to c1, c2, c3, c4 in that order.

func (m *Mat4) Cols(c1, c2, c3, c4 *f32.Vec4)

// Rows sets the rows of m to r1, r2, r3, r4 in that order.

func (m *Mat4) Rows(r1, r2, r3, r4 *f32.Vec4)


I believe that all the methods above should be candidates for inlining in
the Go compiler (at least the indexing methods). So I really don't see
recommending programmers use them for accessing flat matrices as a big
deal. Do people disagree with that?

Cheers,
- Bryan

On Tuesday, March 29, 2016 at 2:31:48 PM UTC-7, laurent....@gmail.com
wrote:
I'm in no way qualified to talk about golang.org/x/mobile/exp/f32, but
I've been toying with OpenGL and Go for some time, and I have a few
question:

- First, and most incompatible, I think the matrix types should be flat
arrays that use column-major order[...]
Why a flat array? As far as I know, on every platform [4][4]float32 has
exactly the same memory layout than [16]float32, but is way more convenient
to use. I'm not too familiar with mobile architectures, so maybe it's
something specific to them? (I don't think the language spec gives anymore
guaranties about padding in one case or the other; in fact, if my
interpretation is correct, as long as a flat array has the right layout,
the two dimensional one should have too).

About the column-major order for storage, in OpenGL you can do both, as
long as you use the correct multiplication order (i.e. row vectors with
row-major matrices). It's true that you have to use column-major storage to
be able to use the "standard" mathematical order in GLSL, so that's
probably a safer choice for a library. Row-major makes some optimizations
possible for affine matrices (at least with the alignment requirements of
some GPUs), but it would make a difference only in a few specific cases
(e.g. skeletal animation).

Finally, I'm not sure I understand the point about serialization in the
render loop. Again, maybe this is specific to mobile platforms, but on
desktop you just provides a pointer to your data, the driver handles the
copy to the GPU. Sure, there is no strong guaranties in the language for
the exact memory layout, but this is also true with C and C++.
--
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

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 17 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 29, '16 at 3:30p
activeMar 31, '16 at 12:58p
posts17
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase