Valuable lesson... Need to go recode with this in mind. Still, it does seem that you're trading speed for memory because you're adding all these matrix multiplications to the paintgl() when you could be passing them as uniforms and letting the shader multiply them.
Not sure if my hardware is the cause or if glm just has updated since this video (probably the later), but I had to use glm::radians(degrees) for both fovy parameter in glm::perspective and for the angle in glm::rotate to get the same results. I imagine these parameters in 2013 were using degrees but they now use radians.
hmm odd why is my left cube getting chopped off. I am using same transformations as the video. seems like its too close to the camera even though same perspective projection is being used.
Your screen width is too narrow. You can either widen your screen so that the apsect ratio math works out, or if you want it to look less distorted, just decrease the z in the translate by 1 or 2 so that the cubes are farther away :D
Hey Jamie, strangley enough i have both cubes spawning and such but when i have the second cube on a rotation of 126* one of the cube's faces seem to disappear, i replaced the angle with 26* and now it works fine? haha
There are a variety of reasons why that could be the case. Do any of your vertices fall outside of the viewing frustum? That could cause one or more vertices to appear offscreen, resulting in OpenGL not drawing that vertex and thus the face along with it. Just had a similar problem happen with me.
It only happens when i apply subdata from the teapot vert and index data. I don't believe they're outside the viewing frustum, but if i tessellate data in paintGL to a number that's somewhat stupid, like 3x for loops (for x, y and z) at the constraint of about 20, and apply the for loop info to the positions (to create a cube of tessellated teapots for etc) then yes, i do recieve the same error. But routinely it's just from loading up the subdata at the start of the program.
So does the computer multiply 'projectionMatrix * translationMatrix * rotationMatrix' from right to left? Because if you did the math from left to right then that would mean you take the projection matrix first and multiply it by translation matrix and then finally multiply that output by rotation matrix which, since the rotation matrix is being multiplied last, would give you undesirable results.
Wow, this is the essence of instantiation.
Valuable lesson... Need to go recode with this in mind. Still, it does seem that you're trading speed for memory because you're adding all these matrix multiplications to the paintgl() when you could be passing them as uniforms and letting the shader multiply them.
Thanks a lot for these tutorials.
Really cool! Better than learning from books.
I thought instancing meant one draw for everything.
Not sure if my hardware is the cause or if glm just has updated since this video (probably the later), but I had to use glm::radians(degrees) for both fovy parameter in glm::perspective and for the angle in glm::rotate to get the same results. I imagine these parameters in 2013 were using degrees but they now use radians.
hmm odd why is my left cube getting chopped off. I am using same transformations as the video. seems like its too close to the camera even though same perspective projection is being used.
Your screen width is too narrow. You can either widen your screen so that the apsect ratio math works out, or if you want it to look less distorted, just decrease the z in the translate by 1 or 2 so that the cubes are farther away :D
Hey Jamie, strangley enough i have both cubes spawning and such but when i have the second cube on a rotation of 126* one of the cube's faces seem to disappear, i replaced the angle with 26* and now it works fine? haha
There are a variety of reasons why that could be the case. Do any of your vertices fall outside of the viewing frustum? That could cause one or more vertices to appear offscreen, resulting in OpenGL not drawing that vertex and thus the face along with it. Just had a similar problem happen with me.
It only happens when i apply subdata from the teapot vert and index data.
I don't believe they're outside the viewing frustum, but if i tessellate data in paintGL to a number that's somewhat stupid, like 3x for loops (for x, y and z) at the constraint of about 20, and apply the for loop info to the positions (to create a cube of tessellated teapots for etc) then yes, i do recieve the same error. But routinely it's just from loading up the subdata at the start of the program.
OH right.. LOL. Wrong Comment.
This no longer seems to be an issue.. Dunno why.. hhahaha
So does the computer multiply 'projectionMatrix * translationMatrix * rotationMatrix' from right to left? Because if you did the math from left to right then that would mean you take the projection matrix first and multiply it by translation matrix and then finally multiply that output by rotation matrix which, since the rotation matrix is being multiplied last, would give you undesirable results.
vertices are hitting the matrices from right to left so it hits rotation then translation then projection
This appear to not be working in 2018, all I get is black window :- (
1:47:
if the GL-wall is open then its useless.