Hi. It worked well for mw, but I have a question. We are linking attribute for location 4,5,6,7 but in the vertex shader we only access location 4 of the type mat4 so how does the shader know that it has to look further?
I'll likely make an animation video in about 2 weeks. For UI you'll have to wait a few more months sadly, since I'll do Physics first after I'm done with OpenGL.
So it looks like I lied... I won't be making an animation tutorial this week since I am having compatibility issues between glm and the glTF format due to different standards for rotation related things. And I just can't figure out what the problem is and how to fix it. So I'll probably do like you said, and make an animation mini-series after the OpenGL series. Sorry :(
Hi. This worked perfectly for me! I have a question. How would I go about updating the model matrices every frame? One way is to create a new vbo and bind it to the vao every frame. Is this the best way or would you suggest something else? Thank you!
Hi Victor, great video as always ! I tried to implement instanciation into an hexagonal map, but I'm confronting several problems : - I need to associate an unique color to each hex in order to read correctly a framebuffer, but it's complicated to modify the VBO without a loop, as I have an unique big model. - Basic hexes will have the same model (a simple hexagon) with different textures, but some won't. Do I have to use, for each different model, an instanciation which groups all the hexagons using this model ? - Navigating around the map is very fast with this system, but modyfing the map with a mouse for example is very slow, because I have to recreate the full map for a single modification. Overall, I feel like instancing is powerful, but not very suitable for quickly modifying the generated objects., but I don't know if I am using this tool well. Should I try to implement it anyways ?
I don't really see why modifying the position/scale/rotation of a hex would be slow... you would just have to modify the part of the array corresponding to that hex. Same with uniqueness, just make an array with all the colors are send them as uniforms to the shader. I hope you know what I mean by an array, basically the same thing I did in the video with the translations. But yeah, I think it would be worth integrating it. Especially if you have hundreds of hexs. My guess is that it would help in the long-run. And it never hurts to practice something new ;)
@@VictorGordan I get the theory, but for the color uniqueness, when can I attribute the color to each hex, as the program is drawing the model once (I was changing the color with uniforms in the drawing loop)
victor,will you also include making game with opengl ,like what thinmatrix did,in jis opengl tutorials,but he did with java,and i need c++?can you later include opengl c++ game tutorial?no one has ever post any tutorial of it in c++
As far as I am aware he simply did tutorials on aspects of OpenGL, which is exactly what I am doing. But I won't be making a tutorial on how to make a specific game because I think that cookie-cutter game tutorials are useless. I cover different general aspects for graphics, and u create the game logic behind them, that's the idea behind my tutorials ;)
@@VictorGordan am i get it correctly that real performance issue is with `bufferData` rather then with `drawElements`? So one should not be afraid to use much `drawXXX` stuff in his code?
Hi Victor, sorry to bother you again but I have some questions about the rotation matrix. I don't really understand how glm::mat4-_cast works, and I'm trying to rotate an hexagon horizontally with a 60° angle, then a 120° angle, then 180°, etc.. I assumed glm:::quat(1.00, 0.00, 0.00, 0.00) represents the absence of rotation and after many tests I found out sending glm::quat(0.87f, 0.0f, 0.5f, 0.0f); to the glm::mat4_cast function outputed (almost) a 60° horizontal rotation. But I don't get the formula behind it. Could you explain it to me ?
First of all, be careful since quaternions are sometimes written as xyzw, and sometimes as wxyz where w is the scaling factor, so just keep that in mind as a possible source of bugs. As for how they work, they are quite weird, give this a watch ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-d4EgbgTm0Bg.html
@@VictorGordan Thanks for the video, it works now! I used glm::quat(glm::radians([ glm::vec3 ofEuler Angles ])) for the conversion. Only problem I have is that the direcLight() fonction in the default shader applies after the rotation, so it looks bad...
I mean yeah, in a real situation you would not want to send them every frame. But the main thing I wanted to show in this tutorial was how instancing works, not how to send data to the GPU effectively ;)
No. Though they have similar effects in a way. The biggest difference is that batch rendering can have multiple models while instancing can only use one model. You can read about some more differences here: www.reddit.com/r/opengl/comments/gvsamp/batch_rendering_vs_instancing_when_to_use_which/? ,and here: www.gamedev.net/forums/topic/511579-batch-vs-instancing/511579/ Hopefully that clears things up! :)
I use a pretty shitty model loader that I made in this series (it's quite limited in what it can do). I think it can load multiple models though... hence the Jupiter and asteroid models. If by your question you meant instancing multiple models, then for that you have two options. You either simply instance an extra model the same way as we did with this one, or you create "clusters" of models which basically means you combine multiple models into a single model in code and then instance that. Hope that helps ;)
