New addon: ofxManipulator

https://github.com/ofnode/ofxManipulator

3D manipulator for OF 0.9.0 that can move objects in space! Partially based on LibGizmo, but I had to clean up code a lot and improve its math.

The result is this :slight_smile:

7 Likes

It looks really good! One question though, why did you make it independent from ofNode?

1 Like

Yes, because ofNode uses this total waste of time and garbage called 4x4 matrix behind the scenes. If ofxManipulator had dependency on ofNode, user could move ofNode and ofxManipulator would get incorrect values for negative scale by calling node.getScale().

all of opengl (and other graphics systems) is based on 4x4 matrices, the problem you were finding is that the decomposition of matrices is not accurate but can be easily solved by storing the values in another variable as ofNode does.

ofNode uses a quaternion to store the rotation, a vector to store the scale and another for the position and then combines them in a 4x4 matrix so it can be easily used as a model matrix in opengl.

another good thing about using ofNode is that you can have a hierarchy of them as you would have in any 3d software program.

1 Like

OpenGL, the standard, does not require 4x4 matrices at all. Historically people use them for convenience on MVP stage, but one can easily get rid of them even there.

It won’t be solved as soon as someone will call setTransformMatrix() directly on ofNode. It won’t update ofNode’s separated scale variable correctly because the only way it can get the scale is through 4x4 matrix decomposition.

yes setTransformMatrix is kind of a comvinience method to set a matrix that you get from other software or some calculation so it can be used as an ofNode but it’s not the way in which an ofNode should be used and the docs should state that using it you’ll loose the access to the separate transformations

1 Like

but it doesn’t make any sense cause the syntax is way more complex and graphics hardware is super optimized for matrix multiplication

My point is it’s a fact that OpenGL doesn’t require 4x4 matrices anywhere in the graphics pipeline, use them or not is up to developers.

One might believe in graphics hardware-accelerated matrix multiplications, others believe in unicorns, but both need evidence before making any statements on the matter. http://stackoverflow.com/a/27028718/1464445

@procedural it would be good if you could keep a more civilized tone. Im just trying to clear out that:

Is totally disproportionate and don’t want anyone looking for info about ofNode or 4x4 matrices to have a wrong impression.

About this link http://stackoverflow.com/a/27028718/1464445 glmatrixmult doesn’t exist anymore in GL3+ and there’s no equivalent in directx since dx10, and in any case that answer you are pointing to, only says that is irrelevant if multiplying the current mvp matrix by another matrix happens in the gpu or the cpu and indeed is even better to do it in the cpu because you do it only once instead of once per vertex. It’s not even what i was talking about.

This link you posted before: http://stackoverflow.com/questions/10094634/4x4-matrix-last-element-significance/10097098#10097098 also doesn’t make any sense, it doesn’t solve the problem you were having since it also mixes the rotation and scaling components. it’s actually just a decomposition of a 4x4 matrix in it’s components.

Using 4x4 matrices to upload the model view and projection to the gpu and transform the geometry there is the standard, is efficient and has a really handy syntax.

You’ve found a problem with 4x4 matrices which is that they don’t preserve the individual transformations, it’s a well known mathematical problem for which there’s approximations but no perfect solution unless you know those transformations beforehand: then you just need to store them separately as ofNode does.

Anyway i don’t want to discuss with you, just clear things out for anyone that might find this thread looking info about ofNode or 4x4 matrices

Ok, then I’ll put it straight, so people won’t get wrong impressions from your statements as well: there’s no such thing as hardware-accelerated 4x4 matrix multiplication on GPU.

The driver decomposes matrices on shader compiling stage and does multiplications on each row and column as you’d do by hand, without any matrix at all.

Right now I’m looking at ISA for AMD’s Southern Islands GPU series and can’t find a single mention or instruction for matrix multiplications. Maybe you can?

i’m not referring to any “hardware accelerated” matrix multiplication, multiplying a vector by a matrix is just a bunch of multiplications and additions which is really fast no matter if it’s in the cpu or the gpu compared to other methods that usually imply using trigonometry. which other method would you suggest it’s faster and more compact than using matrices to transform a geometry?

:sweat_smile:

Very insightful! I myself tried to make ofNode matrix caching to make deep hierarchies faster and it worked out quite okay. It’d be good to have a more efficient ofNode offering the same functionalities, it being such a core class and also procedural’s github name!

There is a clear tradeoff between readability and efficiency in oF code and that’s actually okay given the nature of most users.

Anyhow, thanks for the addon!

3DSMaxやMAYAの操作系を真似て作られたLibGizmoがよくて、それをopenFrameworksに持ってきたofxManipulatorが3次元操作のためにとても使いやすい。

ofxManipulatorを使いやすく改造する.

I wrote an example for 3D-spline editing by using ofxManipulator and MSAInterpolator.
http://cvl-robot.hateblo.jp/entry/2015/12/09/210513

Mr. procedual
Thank you very much for your work!
I am enjoying your libraries.

1 Like

Seems like the link disappeared, but may have reappeared here: https://github.com/u-engine/ofxManipulator