excessive / cpml Goto Github PK

By multiplying A by B in mat4.mul(out, a, b), you are actually multiplying B by A. You say that "composition a*b means "apply b, then a", but there is no such thing as "apply". Matrix multiplication is strictly defined in mathematics, and you came up with something of your own here.

Test case:

package.path = package.path .. ';?.lua;?/init.lua'
local cpml = require 'cpml'

local a = cpml.mat4()
a[5] = 2 -- row 1 column 2
local b = cpml.mat4()
b[2] = 3 -- row 2 column 1

local c = a * b

for i = 1, 4 do
  print(c[i], c[i + 4], c[i + 8], c[i + 12])
end

Expected result:

7	2	0	0
3	1	0	0
0	0	1	0
0	0	0	1

Actual result:

1	2	0	0
3	7	0	0
0	0	1	0
0	0	0	1

Multiplying b*a produces the expected result.

It's obvious from the source. For example, the second row, first column (index 2) in the product a*b should have as a first element the sum of the products of each element in the second row of the first matrix, times each element in the first column in the second matrix. Since the order is column-major, the second row of the first matrix is a[2],a[6],a[10],a[14] and the first column of the second matrix is b[1],b[2],b[3],b[4], yet the code sets it to:

tm4[2] = a[1] * b[2] + a[2] * b[6] + a[3] * b[10] + a[4] * b[14]

and so on, meaning the order is swapped.

Edit: Note that the product, as coded, would have worked in row-major order. Possibly related to #32.

Especially interested in octree

Please add a cpml.mat4.decompose() function that will decompose a matrix into its Vector3 scale, Quaternion rotation, and Vector3 translation components.

Hi, I would like to use this library on my project, but the version of lua that im using is lua 5.2, and the rockspec file requires lua 5.1, is this not compatible at all with any other version, or is it locked by mistake?

I can submit a PR if you need me to.

Do you think we should include a bat file to automate docs for users?
For instance, what I used looks like this:

@echo off
lua "C:\Program Files (x86)\Lua\ldoc\ldoc.lua" %*

I haven't confirmed if I can actually send vectors/matrices as uniforms straight into OpenGL. This would be pretty handy when not using Love2D.

Last I tried, these functions were totally busted. Need to look into why and compare results with another implementation (GLM).

The BSD 2-clause license requires the license text to be retained, but it is not present. That license applies to octree.lua, which LICENSE.md claims to be based on UnityOctree by Nition, so I presume this is the license in question: https://github.com/Nition/UnityOctree/blob/master/LICENCE

Spherical coordinates are basically 3D polar coordinates. I was reading up on them, and apparently there are two common ways to do them, the "physics" way and the "math" way. Is there a certain way anybody likes better than the other?

"Physics" way:

"Math" way

I noticed my PR #59 didn't have the unit tests run, so I checked out the travis config.

I think everything is fine in this repo, but @excessive needs to setup travis on https://travis-ci.com/github/excessive. They shutdown the travis-ci.org builds (where cpml was setup before):

Since June 15th, 2021, the building on travis-ci.org is ceased. Please use travis-ci.com from now on.

Not sure if anything has to change with coveralls.

I did the .org -> .com migration for my projects awhile back and I think I just needed to log into travis-ci.com with my github account, authorize, and then add all repositories to travis.

Hey guys

Thanks for releasing the rock (#18)! We used it and it was great... but the update on Dec 14 broke our app. Could you start versioning as well? If you don't have time we could help make releases from time to time.

I honestly don't expect people to read the code to figure everything out!

Hi. I just stumbled upon the noise code... I didn't realize anybody was actually using it!

In case it's of any use, I did tune those multipliers a bit at the end of each function, see e.g. https://github.com/ggcrunchy/LittleGreenMen/blob/master/lib/simplex_noise.lua#L143 In 2D this brings it up closer to 1.0, in 3D it corrects occasional overshoots (and gets VERY close to 1). 4D, unfortunately, seems to vastly exceed 1 at times, so it's questionable whether the tamed multiplier is even useful any more. 😦 (Apart from those constants I don't recall making any interesting changes.)

Anyhow, if none of this has caused problems for anyone, feel free to ignore.

The tests I made can be found here: https://github.com/ggcrunchy/Strays/blob/master/Unit%20Tests/SimplexNoise.lua

...breaking everything.

workaround: transpose before sending, or use the transpose flag

solution: either transpose to_vec4s, or make sure that cpml isn't actually sideways internally...

Hey guys

Did you consider releasing cpml on LuaRocks? Do you have anything against it?

https://github.com/keplerproject/luarocks

Hi. I'm not sure if it's ok for me to post an issue, but anyway:

--[[ in modules/intersect.lua | starting at line 579 ]]--
local Q1 = A * e1 - d1 * AB
local Q2 = B * e2 - d2 * BC
local Q3 = C * e3 - d3 * CA

vec3 crashes when executing these lines (the d1 * AB-like parts), because it assumes the vector goes on the left side of the operation

easy fix:

local Q1 = A * e1 - AB * d1
local Q2 = B * e2 - BC * d2
local Q3 = C * e3 - CA * d3

Obvious spots include mat4.translate, mat4.rotate, mat4.scale.

quat.from_direction is returning un-normalized quaternions:

for example:
print (quat.from_direction(vec3.unit_x))
prints
(+0.000,+1.000,+0.000,+1.000)

When I run to_angle_axis on the the identity quaternion (0,0,0,1), for example like this

print( cpml.quat.to_angle_axis( cpml.quat() ) )

then the result is

0 (+0.000,+0.000,+0.000)

I expected to get an angle of zero around an arbitray axis instead. The reason is that the identity quaternion is a valid rotation (0 around an axis), and running to_angle_axis on this valid rotation should give me a valid angle and axis, correct?

I had the to_angle_axis buried somewhere deep in my code. Now if I want to keep using it I would need to check for an axis of zero length every time...?

Is there a nice solution? Is this the expected behavior?

There's a scale parameter with a docstring but it doesn't seem to actually do anything.

Please, add module with statistics and distributions

Short version: I am getting incorrect results when composing a quaternion with a pow()ed version of another quaternion. Looking at the code in quat.lua I find

	if dot > DOT_THRESHOLD then
		return a:scale(s)
	end

I don't understand what this means, but if I remove it, I get correct results again.

Long version:

I am generating a random quaternion with

	local RQ = quat.from_angle_axis( (math.random()-0.5)*maxAngle*2, 1,0,0 )
	        * quat.from_angle_axis( (math.random()-0.5)*maxAngle*2, 0,1,0 )
	        * quat.from_angle_axis( (math.random()-0.5)*maxAngle*2, 0,0,1 )

I'm not doing anything to set the seed so I get get consistent values every time I run. I have a quaternion EQ representing the rotation of an object. For each object I am animating RQ:pow(x)*EQ with x interpolating from 0 to 1.

For one of the objects (but not the others), RQ managed to find a "cursed" quaternion CQ; if I print out the xyzq values of CQ with string.format("%f") I get -0.014149,0.020479,-0.006684,0.999668. If I take CQ to a power, I get wacky results. If I take it to a power around 0.05, even though CQ is a very small rotation, this small power of a small rotation results in a huge rotation essentially equivalent to flipping 180 degrees on the X axis. pow() appears to work with quaternions other than CQ.

If I modify my transformation library to automatically normalize quaternions before applying them, the object just sort of jitters and freezes in place; it turns out if I take CQ and raise it to any power less than 1, then normalize, I get -0.019496,0.026780,-0.001824,0.999450 regardless of which power I took it to:

local quatTest = quat(-0.014149,0.020479,-0.006684,0.999668)
print("QUAT TEST", quatTest, quatTest:pow(1/36):normalize(), quatTest:pow(1/2):normalize())

If I remove the if dot > DOT_THRESHOLD block from the definition of pow(), all these problems go away.

I am totally lost. It seems there is a bug in pow(), but I feel afraid just taking the code out since I don't know why it's there?

Making an issue for this. Work is happening in the refactor branch.

• update intersect (8b13679)
• update vec2 (870a3c5)
• update vec3 (1531bf4)
• update quat (85655e6)
• update mat4
• add mat3
• add point functions into vec2 (namely the polar coordinate conversions)
• update docs for vec2 (c5d02e0)
• update docs for vec3 (57704e9)
• update docs for quat (85655e6)
• update docs for mat4
• new tests for vec2
• new tests for vec3
• new tests for quat
• new tests for mat3
• new tests for mat4
• ensure everything works on PUC Lua as well as LuaJIT.

the usage is bad, and it causes math to be more confusing now that mul ordering was fixed a couple years ago. this would be a breaking change and probably prevent an enormous amount of confusing bugs from this legacy bit of the api

it's not really a bug so much as a legacy misfeature that should just go away. a long time ago it made using it easier.

signed, me who just explained the math to someone backwards for the last hour before realizing the logical inconsistency.

When required, the color module will return a table that has as metatable the variable color_mt.
This color_mt contains important metamethods to use in color operations (__add, __mul, to name a few – good for color operations!).

But none of these metamethods are used by the actual color instances because there is no other table that uses color_mt as a metatable, not even indirectly.

Is this intended?

When using mat4.look_at to generate camera transformation matrix the resulting matrix doesn't translate vertices into the camera space properly, resulting in all vertex coordinates being negated. I.e. vertex with coordinates (10, 10, 10) will become (-10,-10,-10) from camera's standpoint.
This is caused by elements 13, 14 and 15 of said matrix being set to 0. Replacing these values with negative dot products (As can be seen here: https://en.wikipedia.org/wiki/Graphics_pipeline#Camera_Transformation ) apparently solves the issue.

CPML documentation states that cpml matrices are column-major.

local testmatrix = cpml.mat4.new{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}

This should be the matrix:

[1  5  9  13]
[2  6  10 14]
[3  7  11 15]
[4  8  12 16]

If so, this prints the opposite results from what is expected:

for _, row in pairs(cpml.mat4.to_vec4s(testmatrix)) do
	print("row: ", row[1], row[2], row[3], row[4])
end
for _, col in pairs(cpml.mat4.to_vec4s_cols(testmatrix)) do
	print("col: ", col[1], col[2], col[3], col[4])
end

row:    1       2       3       4
row:    5       6       7       8
row:    9       10      11      12
row:    13      14      15      16
col:    1       5       9       13
col:    2       6       10      14
col:    3       7       11      15
col:    4       8       12      16

cpml/modules/mat4.lua:

local rx, ry, rz, rw = rot.x, rot.y, rot.z, rot.w

local rm = new {
  1-2*(ry*ry+rz*rz), 2*(rx*ry-rz*rw), 2*(rx*rz+ry*rw), 0,
  2*(rx*ry+rz*rw), 1-2*(rx*rx+rz*rz), 2*(ry*rz-rx*rw), 0,
  2*(rx*rz-ry*rw), 2*(ry*rz+rx*rw), 1-2*(rx*rx+ry*ry), 0,
  0, 0, 0, 1
}

Something about how that rotation matrix is calculated is wrong. Because when I replace it with my own function, that gets the rotation matrix the same way mat4.from_quaternion computes the matrix (using q:to_angle_axis()), I get the correct results that I was expecting:

function dbg_from_transform(trans, rot, scale)
	local sm = cpml.mat4.new{
		scale.x, 0,       0,       0,
		0,       scale.y, 0,       0,
		0,       0,       scale.z, 0,
		0,       0,       0,       1,
	}

	local rm = cpml.mat4.from_angle_axis(rot:to_angle_axis())

	local rsm = rm * sm

	rsm[13] = trans.x
	rsm[14] = trans.y
	rsm[15] = trans.z

	return rsm
end

Sometimes you actually do need those extra percentage points, so we should have an optional UI. We took the outvars out of 1.2.9, but they did have merit.

This could be implemented as foo_inplace which the main function variants wrap with additional checks.

I spent many hours yesterday trying to get the ffi junk to work to no avail. There is a very real 25% performance boost from using ffi, so it's something to consider in the future.

When a nil is passed, it errors, "attempt to index v (a nil value)".

It seems FFI is currently not used for mat4: https://github.com/excessive/cpml/blob/master/modules/mat4.lua#L43

It has been disabled in this commit (2016): 3a18ed0

Is this well-known? Why is it like that? Are there plans to re-enable it?

Problem is as described, there is no documentation for the module. I assume I don't have to explain why documentation is important here.