It's possible as clockwise winding = facing away from the camera. On flat 2D textures it won't make much of a difference unless you have backface culling enabled. But it's a good idea to stick to counterclockwise winding.

Yeah, VBOs are still used with shaders. They are not display lists. They are as you said, a method to store all the object data on the video card for faster, easier access. You can also set things up for instancing which is a super fast way to redraw the same object over and over again with very little performance hit.

Here's a video I created of an asteroid field which has 20K asteroids, each one consists of over 576 vertices totaling around 11.5M vertices. But because the same asteroid object, already in video memory, is redrawn over and over again, just scaled, rotated and translated differently... it can do it blazingly fast.

It would be interesting to try doing this same demo with WebGL and see what sort of performance it gets. It's actually not all that much code for this, relatively speaking.

The problem lies in the order which you send your vertices to WebGL/OpenGL. There is clockwise order, like... the upper left corner first, then the upper right, then the lower left... that would be clockwise, where as the upper left, then lower left, then upper right would be counter-clockwise. In OpenGL, the default order for a face which is... facing you, is counter-clockwise. If you send the vertices in clockwise order, that means the face is facing away from you and you are looking at the backside of it. Now if you have backface culling turned off, not much of a problem, you'll see both sides with a flat polygon. If you enable backface culling, you will see only the side which is facing you, and then it will become a problem.

Here's a good example I googled. You can see the texture on the counter clockwise winding, but not with the clockwise winding, because it is facing away from the camera.

{"name":"611377","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/8\/488ba0f25971e9c5ebc74c5f4a05c9ec.png","w":640,"h":320,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/8\/488ba0f25971e9c5ebc74c5f4a05c9ec"}

There's only one tutorial that I have found on the web about how to do this. Could be more, but I haven't seen any. Which surprises me as this is such an amazing thing as you could see in that last video (and your system is FAR better than mine, I only have an 8 year old CPU and GTX650 video!).

This uses a function called: glDrawElementsInstanced()

You create an array of matrices, in this case, 20000 in size to hold a matrix for each instance of the same object. This way you can use each matrix to change each object's transformation, rotation and scale.

I'll try and find the tutorial online again and post a link here, it was one of the better ones on OpenGL and shaders.

https://learnopengl.com/

The one on instancing is in the advanced opengl section.

Note: he has a PDF you can download of that site as well.

Edit: I just realized he does a FLAT 2D example first, so that's right up your alley!

On that website tutorial, he drew 100K asteroids at 57M vertices!!! My system is a tad slow at that number, I found 20K to be comfortable. You can do it on y our system though.

I almost forgot, I posted a link to a video on doing instancing in Java game programming! (I am "Night Hacker" on that site if you look in the comments).

This is a series you should check out, it seems right up your alley.

Did you check out that video? He does instancing in Java so that would probably be the best bet. Heck, the whole series should be amazing if you like developing for the web. What that guy does with Java and 3D is great. I skimmed though his tutorials, but didn't actually code much of them. What can I say, I like my C + OpenGL, I definitely don't want to use a limited version of OpenGL.

I'm getting all pumped up to do some OpenGL stuff again, glad I read and replied in here. Been needing something to do, haven't been in the programming mood at all lately which sucks as I have been a die hard programmer since around 1980!!

I haven't checked out the video yet (it's late and I don't want to wake anyone with sound from a video). But I will later. Also, the video is Java, not JavaScript. There's a difference.

I've devised a solution to the edit from my last post. Instead of passing the triangle's vertices in pixels and then converting them to clip space, I instead pass them like "normal" from -1.0 to 1.0. Then, in my shader, I have three uniforms: p1, p2, p3--they're all vec2. I then check the points of my triangle in the vertex shader and assign them to p1, p2, or p3 as needed. So this way I think I should be able to reuse the same buffer but change the vertices in the shader! It'll take some more testing to be sure.

LMAO, yeah, I watched a video just the other day where some guy said "Javascript" is the worst name for a language ever because it is neither JAVA, nor is it a Scripting language. That really cleared up my confusion.

Still, I would imagine there are similar solutions or hey, why not code in Java instead? <shrug> I don't know much about the differences. I'll stick to good old C, no bloody #, no bloody Obj, no bloody ++!

Note: as for the tradition which takes place today, thanks for the kind sentiment, but no. I don't do it. I'll just leave it at that. I did have my unleavened bread and wine Thursday night though. That may give you a clue what I do.

Yep. If the face isn't facing you, it won't be lit properly. At least in 3D.

You CAN change the winding you prefer to CW if you wish, I don't know if WebGL supports changing it or not. In OpenGL it is glFrontFace(GLenum mode); where mode is either GL_CW or GL_CCW. It defaults to GL_CCW of course.

There's some good info on it here... https://www.khronos.org/opengl/wiki/Face_Culling

Thanks, it was a nice relaxing evening with the wife. Wine = Baby Duck.... love that stuff!!!

My CPU is an AMD Athlon II X3 440, 3.0 GHz (3 core), I think it is worse than yours. My GPU is a GTX650. I bought it for $100 a few years ago, they now sell for $250! It's insane, I can't see me upgrading anything, anytime soon.

I believe there IS a way to have vertex buffer objects, but change them. Like have the same model data, but use "red color" or "taco texture".

But I've not done it. I might look it up this weekend.

Instancing involves things that repeat a lot, so it is limited, but if you have a scene with say, a lot of trees, all basically the same tree, or tiles of grass, it would benefit them. And when you look at 2D scenes (which you do 2D), much of a scene has a lot of repetition. That is where instancing shines and there is a WebGL command for it...

ext.drawElementsInstancedANGLE(gl.TRIANGLES, indexCount, gl.UNSIGNED_SHORT, 0, instanceCount);

I found a website where someone goes into it with what looks like Javascript to me...

https://blog.tojicode.com/2013/07/webgl-instancing-with.html

From what I understand (and I am fairly new to this as well)... it has to do with how much data you are sending to the card, which is always the main bottleneck in OpenGL or any graphics for that matter.

In general the DrawElements method should be faster, because if Vertices are shared by two or more faces (and it should be like that), than they aren't sent trough the bus twice or more.

In something as simple as a 3D cube, you have 6 faces, each face has two triangles. That's 12 triangles, each has three vertices, which equals 36 vertices total, even though the cube only has 8 vertices, so that's a lot of waste.

On a cube, one vertex on one corner is shared by up to six polygons (triangles), depending on they are set up.

Anyhow, 36-8 = 28 vertices being sent that don't need to be. And each vertex has three floats = 12 bytes per vertex = 36 bytes per vertex, plus any texture info, plus any colour info, multiply that by 36, that's a huge amount of wasted time, and that's just a simple cube!

EDIT: Ooops, messed up my math, that's 6 faces per cube.

Well, even in 2D, if you have a quad, that is four vertices. But if it is made up of two polygons, that equals 6 vertices. Two vertices are being sent twice. Which equals:

2 vertices * 3 floats * 4 bytes per float = 24 bytes
texture co-ordinates equals 2 floats * four bytes per float = 8 bytes
colour information = 3 floats * 4 bytes per float = 12 bytes

Total wasted bytes equals 24 + 8 + 12 or 44 bytes per quad, possibly 56 bytes if you have normal information, unlikely with just 2D, but you would with 3D.

So you end up sending 168 bytes per quad instead of only 112. Multiply that by the number of quads in your scene and it could add up quickly.

Also, if you have a tiled game, than the corners of the quads will also share vertices with the quads neighbouring them, which could be as many as eight vertices at a corner all sharing the same vertex, so even at a mere vertex + texture and no colour or normal information, that's 32 bytes per vertex times 8 vertices equals 256 bytes for that corner verses only 32 for one vertex, which is 224 bytes wasted per corner in a tiled environment.

Yeah, 3D characters in games have "bones". Each bone is attached to certain vertices and you move the bone which adjusts the character's body accordingly.

You can create 3D humans with a free program called MakeHuman (awesome program!) which allows you to easily create characters, human or alien looking (fun to play with) and it will add in bones for you and then you can export it for something like Blender, also free and work from there. It's meant to creating characters for games so useful even for 2D games. Add bones, export to Blender, then use Blender with the bones to pose it and render different positions for your game if it's only 2D.

I've not played with actual characters in a 3D game yet, but that is my understanding. Blender has some simple bone functions you can use and mess with. There's tutorials on it on Youtube as well.

But yeah, the databus is the slowest part of any computer due to the distances it has to travel and that won't go away anytime soon. It's why your RAM is always really close to your CPU, but notice how far away the card slots are, the video slot is always the closest one, but still a distance away for electricity to travel. It's why instancing is so fast, you only upload one VBO to your video card, then tell it where to draw it. You can scale it, rotate it etc... so it looks a little different. You could even upload a texture array, so you have an array of textures the same size then select which one each time you draw it, it's more involved but is something I would like to look into for my own games.

You do not need to recreate a VBO each frame. The whole point of them is that when you create them, they are on the video card and you just refer to them when you wish to use them. Sending them to the card EACH FRAME would be horribly slow!

I created a skybox in my asteroids demo. It creates a VAO and a VBO for it. The VBO etc... are created once outside of the main loop...

// skybox VAO
unsigned int skyboxVAO, skyboxVBO;
glGenVertexArrays(1, &skyboxVAO); // Create Vertex Array Object
glGenBuffers(1, &skyboxVBO);  // Create a Vertex Buffer Object
glBindVertexArray(skyboxVAO);  // Enable the VAO we created
glBindBuffer(GL_ARRAY_BUFFER, skyboxVBO);  // Bind the VBO to the VAO
glBufferData(GL_ARRAY_BUFFER, sizeof(skyboxVertices), &skyboxVertices, GL_STATIC_DRAW); // Store the vertices for the skybox in our VBO
glEnableVertexAttribArray(0);
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);  // Tell OpenGL how the data in the VBO is organized

//plus more code to load the cubemap and skybox shader etc.

Inside my main loop it is...

// skybox shader is enabled before this as well
glBindVertexArray(skyboxVAO);  // Enable the VAO which contains our VBO
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_CUBE_MAP, cubemapTexture);  // Use our cubemap
glDrawArrays(GL_TRIANGLES, 0, 36);  // Render our skybox using the VAO/VBO and cubemap

That's all that is called inside the main loop. The VBO is bound in the VAO, you can have several VBOs in a VAO, the actual data is in the VBO(s). Again, I am still fairly new to this, but slowly getting a grasp of it.

I do know the point of a VBO is so you have all the data for that object loaded on the video card at once, then you just tell the video card when you are using it. The VBO is stored in the VAO (you can have more than one VBO in a VAO). The speed comes in the fact that it is already on the card and doesn't need to be reloaded.

In the above code, you bind the vertex array, which tells your program which VAO you are now using. You then bind a texture to it and draw the arrays which contain the triangles as I showed above. No need to recreate it all, you use glBindVertexArray() (or the WebGL equivalent) to tell the program which VAO you are now using. It will remain bound (the one in use) until you call glBindVertexArray(0); which unbinds it.

Watch this video for a great description of what VAOs and VBOs are.

Edit: added more comments and better described my source