issue porting C++/glm/openGL to D/gl3n/openGL
Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. // C++ glm opengl code glm::mat4 transform; transform = glm::translate(transform, glm::vec3(0.0f, -0.5f, 0.0f)); transform = glm::rotate(transform, 45.0f, vec3(0.0f, 0.0f, 1.0f)); // degrees // D gl3n opengl code mat4 transform = mat4.identity; transform = transform.translation(vec3(0.5f, -0.5f, 0.0f)); transform = transform.rotate(0.78539, vec3(0.0f, 0.0f, 1.0f)); // radians My D code performs the operations fine, but in the _opposite_ order. I thought just swapping the order would fix things: transform = transform.rotate(0.78539, vec3(0.0f, 0.0f, 1.0f)); transform = transform.translation(vec3(0.5f, -0.5f, 0.0f)); but now the square is moved to the lower right corner but no rotation happened? So am I using gl3n incorrectly? Are there tricks or techniques I' missing? Is gl3n not a direct replacement for glm? Any advice is greatly appreciated. Thanks.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to start with the glm documentaion [1]. [1] http://dav1dde.github.io/gl3n/
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 04:37:43 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to start with the glm documentaion [1]. [1] http://dav1dde.github.io/gl3n/ Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) I bought your excellent book as a xmas present for myself so looks like I'll be reading chapter 9.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. [...] iirc, gl3n uses row major and glm uses column major ordering just pass GL_TRUE to the transpose argument in glUniformMatrix4fv
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 06:35:34 UTC, rsw0x wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. [...] iirc, gl3n uses row major and glm uses column major ordering just pass GL_TRUE to the transpose argument in glUniformMatrix4fv Yup. Have that already. Maybe I'll take snapshots of the transform matrix of both programs and see how they differ (if any). The vertex shader is identical for both.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: I thought just swapping the order would fix things: transform = transform.rotate(0.78539, vec3(0.0f, 0.0f, 1.0f)); transform = transform.translation(vec3(0.5f, -0.5f, 0.0f)); but now the square is moved to the lower right corner but no rotation happened? (Disclaimer: I know absolutely nothing about gl3n.) Note that you wrote "translatION", instead of "translatE". Reading the documentation, "translation" does not apply but instead it sets the matrix to a certain translation. See the difference between "rotate" and "rotation" methods. It's pretty strange that there is no "translate" method...
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 10:35:34 UTC, Johan Engelen wrote: It's pretty strange that there is no "translate" method... Didn't see it in the online docs, but in the source there is the "translate" method that you should use.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 10:38:07 UTC, Johan Engelen wrote: On Sunday, 10 January 2016 at 10:35:34 UTC, Johan Engelen wrote: It's pretty strange that there is no "translate" method... Didn't see it in the online docs, but in the source there is the "translate" method that you should use. That's it! Excellent catch. Thank you. gll3n has translate(), rotate(), and scale() and matrix operators. It also has translation(), rotation(), and scaling() which /// Returns a translation matrix (3x3 and 4x4 matrices). /// Returns an identity matrix with an applied rotate_axis around an arbitrary axis (nxn matrices, n >= 3). /// Returns a scaling matrix (3x3 and 4x4 matrices);
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 06:35:34 UTC, rsw0x wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. [...] iirc, gl3n uses row major and glm uses column major ordering just pass GL_TRUE to the transpose argument in glUniformMatrix4fv If you like to check an D lib for vector/matrix/quaterntion operations that uses column major ordering (ie, not need to transpose), see this : https://github.com/Zardoz89/zmath Was just my D2 learning pet project... I never checked if it was math correct, and I don't updated in a lot of time (5 years ago), plus there isn't documentation beyond comments and a few unit-tests, so use at your risk. But at least I know that was working correctly with Derelict2 when I wrote it. Perhaps I should retake this...
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Monday, 11 January 2016 at 10:04:29 UTC, Luis wrote: On Sunday, 10 January 2016 at 06:35:34 UTC, rsw0x wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. [...] iirc, gl3n uses row major and glm uses column major ordering just pass GL_TRUE to the transpose argument in glUniformMatrix4fv If you like to check an D lib for vector/matrix/quaterntion operations that uses column major ordering (ie, not need to transpose), see this : https://github.com/Zardoz89/zmath Was just my D2 learning pet project... I never checked if it was math correct, and I don't updated in a lot of time (5 years ago), plus there isn't documentation beyond comments and a few unit-tests, so use at your risk. But at least I know that was working correctly with Derelict2 when I wrote it. Perhaps I should retake this... I just remember why I never retake this ... Use gl3n, row-major math operations outperforms a lot, if you are doing any matrix multiplication on CPU side ( http://eli.thegreenplace.net/2015/memory-layout-of-multi-dimensional-arrays/ )
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: On Sunday, 10 January 2016 at 04:37:43 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to start with the glm documentaion [1]. [1] http://dav1dde.github.io/gl3n/ Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) I bought your excellent book as a xmas present for myself so looks like I'll be reading chapter 9. gl3n has most features of GLM just the syntax is different and a few other things. gl3n then operates on row-major matrices only (Extrawurst wanted to work on a column-major version), which isn't a big issue for your usual GL, you just need to tell OpenGL that it is in row-major format when uploading it. iirc GLM is a header only library so you can't simply interface it from D you would need to port every function, that's what I basically did in gl3n only that I started from scratch and made my own API etc. So you can use gl3n as a glm replacement it just has a different syntax and a few semantics are different. --- Regarding some functions not showing up on the website, that's because the ddoc generator doesn't want to go into some static if() or version() blocks. A known bug.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) AFAIK, glm is a header-only library, so there's nothing to bind to. And if it did have binaries, I don't think the current state of D's C++ support could handle it. Binding to C is easy, binding to C++ is hit or miss.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Tuesday, 12 January 2016 at 01:00:30 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) AFAIK, glm is a header-only library, so there's nothing to bind to. And if it did have binaries, I don't think the current state of D's C++ support could handle it. Binding to C is easy, binding to C++ is hit or miss. the performance would also be terrible because AFAIK nothing could be inlined(outside of LTO, maybe)
