zuzu-typ / pyglm Goto Github PK

Hello, I am a beginner. I don't know how to use C++ for OpenGL. It is difficult for me. I want to use python for OpenGL. I find the PyGLM is very useful and I am interested in it. But I find it isn't have document and tutorials. So I don't know how to learn it, how to use it. On the other side, I don't want to read the OpenGL document which wrote use C++.

Could you provide some document which I can learn PyGLM using Python. As far as I am concerned, many people can't learn GLM because it is written in C++. The library you build could help millions of people. But only PyGLM library is not enough, they need document, tutorials to study, to learn. So if you could provide some document for PyGLM written in python may help millions of people. If you need help, I would be like to help you.

Thank you so much!

This works as expected:
x = glm.vec4(6.0)
v = glm.vec4(4.0, 4.0, 4.0, 4.0)
x * v

but this produce an exception
x = glm.vec4(6.0)
m = glm.mat4(3.0)
m * x

with python 2.7 and python 3.6, python3 give a better stack dump than 2.7
Traceback (most recent call last):
File "/usr/lib64/python3.6/site-packages/glm/detail/type_mat4x4.py", line 157, in __mul__
return self.row_type(value.arr.reshape(4) * self.value)
ValueError: total size of new array must be unchanged

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "test_glm.py", line 18, in
print(glm.mat4(3.0)*x)
File "/usr/lib64/python3.6/site-packages/glm/detail/type_mat4x4.py", line 172, in __mul__
raise TypeError("unsupported operand type(s) for *: 'tmat4x4' and '{}'".format(type(value)))
TypeError: unsupported operand type(s) for *: 'tmat4x4' and '<class 'glm.detail.type_vec4.tvec4'>'

I see there is a lot of commented code everywhere in mat*.py to try to handle various type but perhaps a better way to handle that is in tvecX.init to create a numpy array of the right size. I didn't try but what about (2/3 for tvec2/tvec3):

if type(args[0]) in dtypes:
self.arr = numpy.array([args[0]]*4, dtype=self.dtype)

There should be a way to set a list of "preprocessor definitions" for PyGLM.
This should include
GLM_FORCE_CTOR_INIT,
GLM_COORDINATE_SYSTEM,
GLM_CLIP_SPACE
and any other that make sense to be implemented.

follow up of #6 after commit 53c5959 I see now memory leak with:

a = glm.mat4()
b = glm.mat4()
for _ in range(5*10000000):
    a += b

same with a = a + b

Zuzu-Typ reported to see no leak but some crash/wrong result with __iadd__ probably same issue. Python3 show no trouble. refcount is messed somewhere imho.

GLM allows for either MIT or Modified MIT, see here:

https://github.com/g-truc/glm/blob/master/copying.txt

Having this project under both MIT (for PyGLM) and modified MIT (GLM) causes some odd legal headaches. Can we just stick to using the standard MIT liscense found here?

================================================================> ================
OpenGL Mathematics (GLM)

GLM is licensed under The Happy Bunny License or MIT License

[sic]

================================================================> ================
The MIT License

**Copyright (c) 2005 - 2014 G-Truc Creation

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Currently COPYING.txt and LISCENSE.txt use the "and" version.

This is example code I'm trying to use.

self._campos.xz = mat2(c, -s, s, c) * self._campos.xz

This issue forces to write less intuitive code.

xz = mat2(c, -s, s, c) * self._campos.xz
self._campos.x = xz.x
self._campos.z = xz.y

with python2.7

import glm

a = glm.vec2()
a.x

coredump with a segmentation fault, pull request coming soon to fix it

please add them, it's a bit boring to need to get them from pypy tar file.

I try to use PyGLM and PyOpenGL together but it appears there is no way to glue these two libs. Maybe I'm missing something.

Converting a list of vec to numpy array produces an error (I guess in the iterator protocol)

numpy.array([vec3(1,0,0), vec3(0,1,0)])

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'vec3Iter' object is not iterable

The same happends for vec2 and vec4 of course

Converting a list of mat to numpy array produces a more weirded error

numpy.array([mat2(1), mat2(0)])

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: mat2x2( 1, 0 | 0, 1 )

As the vec and mat are iterables (iterable over iterables for mat), they should be able to work with the numpy array function, right ?

There seems to be an ongoing issue on Travis CI, due to which PyGLM's Windows builds aren't uploaded.
I've already contacted their support team.

Hopefully this can be quickly resolved so the windows users out there don't have to wait for v1.2.0 to deploy much longer.

Cheers
--Zuzu_Typ--

Hi, first I have to congratulate you for this so conveinient library !
I tried the following:
copy.deepcopy(glm.vec3(1))
copy.copy(glm.vec3(1))

in both cases, I get the following error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/copy.py", line 96, in copy
    rv = reductor(4)
TypeError: can't pickle glm.vec3 objects

I think that for wrapped objects it's done using the __reduce__ or the __deepcopy__ method.
I use these vectors and matrices in classes to represent points of primitives, I need to copy these Primitive objects.
Can you please implement the copy protocol for the glm objects ?

It would be nice to have manylinux and macosx/darwin wheels on pypi. I guess it doesn't really matter too much for linux, but at least for darwin users it's not really straight forward to compile pyglm.

I'm a big fan of things working out of the box for win/linux/darwin for all my pacakges, so this is might an improvement to look into. Ci systems can do this today as well.

import glm
glm.mat4(1.0) / glm.vec4(1.0)
tvec4( 1, 1, 1, 1 )

I don't see in the glsl specs where this is allowed, glm.mat4(1.0) * 1.0/glm.vec4(1.0) is well defined but the expression above should raise a TypeError. Did I miss something? or does c++ glm allow that?

I got the source and did a:
python setup.py build

and it said:
pyglm.c(4) : fatal error C1083: Cannot open include file: 'stdbool.h': No such file or directory

so I copied:
`#ifndef _STDBOOL_H
#define _STDBOOL_H

#ifndef __cplusplus

#define true 1
#define false 0
#define bool _Bool

#endif

#define __bool_true_false_are_defined 1

#endif
`
to C:\Python27\PC and now it returns a bunch of errors saying:

c:\downloads\pyglm-master\glminternalfuncs.h(1148) : error C2143: syntax error : missing ';' before 'type' c:\downloads\pyglm-master\glminternalfuncs.h(1149) : error C2065: 'oneOverLen' : undeclared identifier c:\downloads\pyglm-master\glminternalfuncs.h(1149) : error C2065: 'oneOverLen' : undeclared identifier c:\downloads\pyglm-master\glminternalfuncs.h(1149) : error C2065: 'oneOverLen' : undeclared identifier c:\downloads\pyglm-master\glminternalfuncs.h(1149) : error C2065: 'oneOverLen' : undeclared identifier c:\downloads\pyglm-master\glminternalfuncs.h(1160) : error C2061: syntax error : identifier 'iconjugate'r

Any ideas what is going on?

pip install pyglm

Installed version via glm.version() is v0.3.6

import  glm
glm.mat4()

Results in AttributeError: module 'glm' has no attribute 'mat4'

Cloning this repo and installing via python setup.py install produces the expected output.

I was testing np.clip(-0.010945739779012037, -1.0, 1.0) vs glm.clamp(-0.010945739779012037, -1.0, 1.0) and I get -0.010945739779012037, and -0.010945740155875683, when both should just be -0.010945739779012037. This appears to be because glm.clamp is doing a f32 conversion, which it shouldn't be doing.

Looking at the code I see this on line 27487:

PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf(clamp)

Looking at PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf shows:

#define PyGLM_MAKE_GLM_FUNC_NNN_VVV_VNN__tf(NAME)\
static PyObject*\
NAME##_(PyObject*, PyObject* args) {\
	PyObject *arg1, *arg2, *arg3;\
	PyGLM_Arg_Unpack_3O(args, #NAME, arg1, arg2, arg3);\
	if (PyGLM_Number_Check(arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(PyGLM_Number_FromPyObject<float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(1, float, arg1) && PyGLM_Vec_Check(1, float, arg2) && PyGLM_Vec_Check(1, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<1, float>(arg1), unpack_vec<1, float>(arg2), unpack_vec<1, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(2, float, arg1) && PyGLM_Vec_Check(2, float, arg2) && PyGLM_Vec_Check(2, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<2, float>(arg1), unpack_vec<2, float>(arg2), unpack_vec<2, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(3, float, arg1) && PyGLM_Vec_Check(3, float, arg2) && PyGLM_Vec_Check(3, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<3, float>(arg1), unpack_vec<3, float>(arg2), unpack_vec<3, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(4, float, arg1) && PyGLM_Vec_Check(4, float, arg2) && PyGLM_Vec_Check(4, float, arg3)) {\
		return pack(glm::NAME(unpack_vec<4, float>(arg1), unpack_vec<4, float>(arg2), unpack_vec<4, float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(1, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<1, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(2, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<2, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(3, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<3, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	if (PyGLM_Vec_Check(4, float, arg1) && PyGLM_Number_Check(arg2) && PyGLM_Number_Check(arg3)) {\
		return pack(glm::NAME(unpack_vec<4, float>(arg1), PyGLM_Number_FromPyObject<float>(arg2), PyGLM_Number_FromPyObject<float>(arg3)));\
	}\
	PyErr_SetString(PyExc_TypeError, "invalid argument type(s) for " #NAME "()");\
	return NULL;\
}

There's not a single reference to double, so it seems apparent that this macro is not capable of handling double precision code arguments. I'm not sure exactly what this is doing, and it makes it difficult to contribute since it is one giant file, but I assume if everything here is just copied again but with double as the parameter it should just work? All the other similar macros appear to reference double, so presumably anything that uses that macro is going to have this same bug.

I think the frexp and ldexp functions should take a single argument and return a pair, just like the standard python version https://docs.python.org/3.5/library/math.html#math.frexp, because python parameters are passed by value. That's more python-friendly.

Another solution would be to pass an array of ints as the second parameter.

Currently numpy arrays can't be converted to glm matrices.

This should be done using the buffer protocol.

Thanks for this library. I have been waiting for it for almost 2 years. Great work.

But I do have a question about how to use it.

Before I found this library, I use numpy and just pass ndarray to functions in PyOpenGL, like glUniformMatrix4fv.

Do I need to convert the glm data types before giving them to these functions?

Is it possible to unify criteria about list and str conversions for mat and vec?

vec (for me, a very good criteria)
str(glm.vec3()) returns class representation with values, OK
list(glm.vec3()) returns a list of values, OK
json.dumps( list(glm.vec3())) nice code to convert to json string, OK
glm.vec3( json.loads( "[1,2,3]")) nice code to parse a json string, OK

mat (some missig fucntionalities)
str(glm.mat3()) returns a formatted string with values (not class representation), OK
list(glm.mat3()) return a list of mvec3...some times you prefer a list of lists... semi ok...
[list(mv) for mv in glm.mat3()] pretty nice code to have a list of lists, OK
json.dumps([list(mv) for mv in glm.mat3()]) not super nice code, but OK
There is no way to do an inline json.loads from a json string. Is it?

Hi,
it's me again.

we can yet convert vectors between simple and double types, for example fvec3 <-> dvec3 using the constructor:

>>> fvec3(dvec3(1))
vec3( 1, 1, 1 )

but the same seems to not exist for matrices:

>>>  fmat4(dmat4(1))
TypeError: invalid argument type(s) for mat4x4()

My current solution is to use the constructor from an iterator, such as

>>> fmat4(*dmat4(1))

This way the dmat4 gives an iterator of python objects, that are used as a sequence of arguments for fmat4. But this approach is not efficient nor aesthetic.

Can you possibly implement it ?

cut and copy error in vec3 and vec4 __ne__

print(glm.vec4(1.0, 1.0, 1.0, 0.0) != glm.vec4(1.0, 1.0, 1.0, 1.0))
False

PyGLM should support more datatypes in the future, including custom ones using vec<n, T, Q>.

PyGLM should also support the precision qualifiers.

Hi,
are you planning to add support for the experimental extensions (GTX)? I am trying to port a c++ code to python which uses the glm::decompose function.

Also, thanks for this project. Makes my work a lot easier right now. :)

Hi,
pip install pyglm fails with all versions between 0.5.0b1 and 0.5.2b1 on macOS 10.13.6 with Xcode 10.1, see gist: https://gist.github.com/devernay/9601e4ad7c0a270b05e80016483a7810

Installing 0.4.8b1 with pip install pyglm==0.4.8b1 succeeds.

My initial guess is that it is probably due to using clang to compile it.

When i do ivec2(1) / ivec2(0) or any other division of int vector by 0 python crashes:
Process finished with exit code -1073741676 (0xC0000094)

P.S. PyGLM version: 1.1.8, latest pypi version for now.

Is that possible to add a norm function to use the L1 and L infinite norms instead of L2 (euclidian norm) ?
These norms have often the advantage of being faster (no float product and square root)

Something like norm1, norminf or length1, lengthinf
Then for coherence, it would be nice to define an alias to the current length function named along length2 or norm2

cross function is always returning float vectors, not double.

a1 = glm.dvec3(random.random(), random.random(), random.random());
a2 = glm.dvec3(random.random(), random.random(), random.random());
a1
>>> dvec3( 0.784963, 0.180989, 0.458512 )
 a2
>>> dvec3( 0.291617, 0.296031, 0.0420636 )
glm.cross(a1,a2)
>>>vec3( -0.128121, 0.100692, 0.179594 )

Functions such as max, min and clamp throw a TypeError when used with int vectors:

>>> glm.max(glm.ivec2(5), glm.ivec2(4))
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: invalid argument type(s) for max()

Is is possible to get the polar coordinate extension included?

https://glm.g-truc.net/0.9.2/api/a00285.html

or is it not stable enough?

The order of quaternion components is not consistent in glm.
E.g. the constructor has the order (w, x, y, z) - which is the most logical order to me, while the internal representation is (x, y, z, w).
This has been addressed by g-truc already, by adding a preprocessor definition GLM_FORCE_QUAT_DATA_WXYZ.

I do wish to adapt to this, although it will break code that was previously written for quaternions.

I have found what looks like a memory leak in glm.normalize. I tested it on two different systems with the below code, and found the memory of the process quickly increased.

while True:
    glm.normalize(glm.vec2(0, 0))

The inplace power function of all of the vertex types makes Python crash.

I have started investigating, but didn't find a way to get it to work - not even when it does nothing but return self.
I guess I'll need to try around some more.

Example from mat_getbuffer

if ((flags & PyBUF_RECORDS_RO) != PyBUF_RECORDS_RO || (flags & PyBUF_F_CONTIGUOUS) == PyBUF_F_CONTIGUOUS || (flags & PyBUF_ANY_CONTIGUOUS) == PyBUF_ANY_CONTIGUOUS) {
	PyErr_SetString(PyExc_BufferError, "This type of buffer is not supported.");
	view->obj = NULL;
	return -1;
}

Most types (if not all) do pass the PyBuffer_IsContiguous() tests, so I assume all types have contiguous buffer data. Still, the various *_getbuffer methods do not accept this flag.

We discovered this issue when trying to set uniform or buffer data in moderngl.

program['uniform'].value = (1, 1, 1)    # working
program['uniform'].write(np.array([1,1,1]))    # working

v = glm.fvec3(1,1,1)
program['uniform'].write(memoryview(v))    # working
program['uniform'].write(bytes(v))    # working
program['uniform'].write(np.array(v))    # working

program['uniform'].write(v)    #  <--------- error

Error output:

BufferError: This type of buffer is not supported.

We obtain the buffer using:

PyObject_GetBuffer(value, &buffer_view, PyBUF_SIMPLE);

This is acceptable when you just want to write contiguous to an opengl buffer and have no plans to keep the buffer reference or modify it.

More details here:
moderngl/moderngl#379

shortest script to reproduce the problem:

import glm

while True:
    for _ in glm.vec4(1.0):
        pass

This fragment of code segfault after a few iteration with python 2.7, backtrace is:

#0  0x00007f8b342d59c0 in PyCode_Type () from /usr/lib64/libpython2.7.so.1.0
#1  0x00007f8b3405dedf in ?? () from /usr/lib64/libpython2.7.so.1.0
#2  0x00007f8b33fcb3d6 in ?? () from /usr/lib64/libpython2.7.so.1.0
#3  0x00007f8b3405e187 in ?? () from /usr/lib64/libpython2.7.so.1.0
#4  0x00007f8b3405f0db in _PyObject_GC_Malloc ()
   from /usr/lib64/libpython2.7.so.1.0
#5  0x00007f8b3405f176 in _PyObject_GC_NewVar ()
   from /usr/lib64/libpython2.7.so.1.0
#6  0x00007f8b33fcbc6f in PyTuple_New () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007f8b34041bde in ?? () from /usr/lib64/libpython2.7.so.1.0
#8  0x00007f8b3404107f in ?? () from /usr/lib64/libpython2.7.so.1.0
#9  0x00007f8b340420f7 in Py_BuildValue () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007f8b2f308ac9 in tvec4_geniter (self=<optimized out>)
    at type_vec4.h:986
#11 0x00007f8b33f6a1fe in PyObject_GetIter ()
   from /usr/lib64/libpython2.7.so.1.0
#12 0x00007f8b340195cf in PyEval_EvalFrameEx ()
   from /usr/lib64/libpython2.7.so.1.0
#13 0x00007f8b34021d4c in PyEval_EvalCodeEx ()
   from /usr/lib64/libpython2.7.so.1.0
#14 0x00007f8b34021e69 in PyEval_EvalCode ()
   from /usr/lib64/libpython2.7.so.1.0
#15 0x00007f8b3404601a in PyRun_FileExFlags ()
   from /usr/lib64/libpython2.7.so.1.0
#16 0x00007f8b340473a7 in PyRun_SimpleFileExFlags ()
   from /usr/lib64/libpython2.7.so.1.0
#17 0x00007f8b3405d89e in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#18 0x00007f8b3323e7d0 in __libc_start_main () from /lib64/libc.so.6
#19 0x0000000000400779 in _start ()

with python3 I only see a rare segfault when killing the script with Ctrl-C, the backtrace is:

#0  0x00006465736f6c63 in ?? ()
#1  0x00007fa222f3339f in ?? () from /usr/lib64/libpython3.6m.so.1.0
#2  0x00007fa222e625b6 in ?? () from /usr/lib64/libpython3.6m.so.1.0
#3  0x00007fa222f32707 in ?? () from /usr/lib64/libpython3.6m.so.1.0
#4  0x00007fa222f33769 in PyGC_Collect () from /usr/lib64/libpython3.6m.so.1.0
#5  0x00007fa222f10643 in Py_FinalizeEx () from /usr/lib64/libpython3.6m.so.1.0
#6  0x00007fa222f31663 in Py_Main () from /usr/lib64/libpython3.6m.so.1.0
#7  0x0000000000400b92 in main ()

A part of the python 2.7 backtrace is not reliable, sometime the bt does not contains tvec4_geniter nor any glm function but near the top of the bt there is always some python runtime call related to memory alloc/dealloc or garbage collection. Look like the vec4 iterator interface mess up the python memory allocator.

After attempting to put in a glm.vec3 in glm.euclidean, I was met with an error about it being an invalid argument. Upon further inspection, it appears that while both GLM's documentation and text documentation inside of PyGLM.cpp ("euclidean(v) -> vec3\nConvert Polar to Euclidean coordinates.") state that vec3 is the input, the function was generated with a macro that takes only vec2 as input

PyGLM_MAKE_GLM_FUNC_V2__tfF(euclidean)

I believe the above should be changed to

PyGLM_MAKE_GLM_FUNC_V3__tfF(euclidean)

I don't know if this a coincidence, but neither polar nor euclidean have auto generated python stubs for documentation purposes. Polar, for example, can be used, but doesn't have anything in glm/__init__.py which is generated.

There are a bunch of memory leaks hidden somewhere in PyGLM.

Please locate and fix them.

Best of luck!
~me

>>> glm.mat4(1.0) * glm.vec4(1.0)
vec4( 1, 1, 1, 1 )
>>> glm.mat4(1.0) * glm.dvec4(1.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'glm.vec' and 'glm.mat4x4'
>>> glm.dmat4(1.0) * glm.vec4(1.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'glm.vec' and 'glm.dmat4x4'
>>> glm.dmat4(1.0) * glm.dvec4(1.0)
dvec4( 1, 1, 1, 1 )

Thanks!

Seriously, how can we give you more stars for this?
It's amazing to have same library in Python, C++, .NET.
Many thanks! You can close this issue now...

I tried to use the original glm documentation. But since there is about 95% missing in PyGLM, it's not a well working approach. So while I think this is a good project, it's not an option if you have the desire to get something done.

The PyGLM_test.py testing suite needs more tests.
Every function should be checked on working correctly.

Hi, I got an issue with item assignment of matrices, the simple code below is sufficient to make python crash after about 50 assignments:

from glm import *

for i in range(100000):
	print(i)
	m = mat4(1)
	m[3,2] = 1

on linux, I get the following output

...
45
46
47
48
munmap_chunk(): invalid pointer
Abandon

I'm using pyglm from pip:

$ pip3 show pyglm
Name: PyGLM
Version: 1.1.7

The strange thing is that the crash is extreemly reproductible (always occurs after the same number of iterations) and it occurs also with smaller indices after some more iterations (such as m[1,1], m[0,0], ...)
It's also the same with inplace operations such as m[1,1] += 1

Do you have an idea ?

Currently, PyGLM does not support all stable glm extensions (GLM/GTC).
This should be fixed in the future.

Are you planning to add support for PyPy? It seems that the current version of PyGLM is not compatible with it, I got a lot of compilation errors when trying to install via pip.

I have this from a tutorial:

vec = glm.vec4(1.0,0.0,0.0,1.0)
id_matrix = glm.mat4()
trans_matrix = glm.translate(id_matrix, glm.vec4(1.0, 1.0, 0.0))
vec = trans_matrix * vec

printing vec gives 0.0,0.0,0.0 and I was expecting 2.0,1.0,0.0

Please help! Thanks

a = glm.vec4(4.0)
a = a + 2.0

TypeError: unsupported operand type(s) for -: 'glm::detail::tvec4' and 'float',

python 2.7 require Py_TPFLAGS_CHECKTYPES to allow to call numeric method with different types, py3 doesn't need nor define this flag.

I just realized, that glm's matrix classes have a flaw in them.
They create a CxR matrix and not the mathematically correct RxC matrix.

So a normal mat2x4, would have 2 rows and 4 columns, but a glm.mat2x4 has 2 columns and 4 rows instead.
This is especially obvious with the glm.column() and glm.row() functions, which seem to do the opposite of what they're supposed to, when looking at the output of printing a matrix to the console:

>>> m24 = glm.mat2x4(1,2,3,4,5,6,7,8)
>>> print(m24)
[ 1 | 2 | 3 | 4 ]
[ 5 | 6 | 7 | 8 ]

>>> glm.row(m24, 0)
vec2( 1, 5 )

>>> glm.column(m24, 0)
vec4( 1, 2, 3, 4 )

I'm not exactly sure how I should face this now, as it will most definitely not be changed in the original glm version.
I could...

1. Not do anything about it at all and try to leave notes about it in documentation
2. Try to swap the order of columns and rows and risk destroying something
3. Change the way matrices are printed to fit the way they're represented by glm
4. ...?

I need some opinions on this before I can decide.