วีดีโอ

Thanks for the feedback. The plan is indeed to render the entire frame using a single buffer. This will happen later on in the series once I finish with the basics.

If you have no prior knowledge of 3D rendering then definitely start with OpenGL. Vulkan is much more complex but at least the math part is the same so you will learn that with OpenGL.

Glad it helped!

You're welcome :-) There is a roughness factor in the midpoint displacement algorithm. Is that what you mean?

@@OGLDEV In the last video about tessellation shaders, the LOD depended only on distance from camera. How about adding some kind of roughness factor for the patch, influencing final LOD tessellation level? Anyway, thanks for the good content!

Not sure if this will improve the visual result. This would mean that you will have different LODs in regions which are the same distance from the camera. Perhaps you can add a texture with random numbers and use them to offset the height at the interpolated points. I haven't tried that though.

Yep, this is called slope based texturing. I will probably implement it at some point.

Sorry, I didn't understand this comment.

@ pot = power of two, hf = heightfield

OK, got it. Yes it makes sense. The algorithm continues running under the same constraint but from there you can resample the heights to any size between two consecutive power of two.

You can group sets of shaders into different program objects and call glUseProgram(ProgHandle) to switch between the programs. In my shadow mapping videos you can see an example of a shader program for rendering into the shadow map and another program for rendering into the color buffer.

What do you mean by use multiple shaders? OpenGL only support bind one shader to the state machine at a time. If you have multiple materials with different shaders, just bind them sequentially and on each binding, render the meshes associated with the shader.

@@赟杨 oh wow thanks!

Do you mean the screen position?

Sorry, I didn't understand this comment.

You're welcome! Thanks for the feedback, you may be right on the YZ vs ZY issue but it's been so long since this video was published so I need to spend some time to look into this...

You're welcome :-)

The question is whether this is a bug or simply incorrect or badly tuned params of the light/material properties. You can take the assets and lighting params from an existing app that seems to work correctly and plug them into your sample to compare.

See Listing 4 Determine whether a screen position is on screen. With bitwise and to combine all culling bits to final bitmask, say frustumBits, one can tell if frustumBits is not zero, then the bounding box can be culled.

I think you answered it at 23:25, going through it again

Yes, this is a combination of two quaternions: a rotation around 1,0,0 by the y-delta (y,0,0) and a rotation around 0,1,0 by the x-delta (0,x,0). Combine them together to get y,x,0.

Got it, mouse x rotates on y up, mouse y rotates on x right

No good reason, but note that the check is identical: !Success is TRUE if Success equals to zero. I will make them consistent. Will go into my next commit. Thanks for the feedback.

@@OGLDEV Thanks.. I wrongly assumed that the condition checks were different

Appreciate it!

Well, we have to keep moving forward...

You're welcome! You can use my affiliate links: ogldev.org/books.html ;-)

Do you mean that the standard rectangular shadow map was populated correctly but the cube map was not? I don't think it has anything to do with the number of channels. The cubemap is actually a color buffer because (afaik) we can't use a cubemap as a depth buffer. So we render the depth explicitly as a color value which means that it is subject to blending operations.

@OGLDEV at one point I copy-pasted your code to make sure I wasn't making some coding mistake. It still wasn't working so I used Nvidia Nsight and Renderdoc to check it and the depth texture looked correct but as mentioned the cubemap did not render (every pixel was max float). So the glClear worked but the actual drawing of the elements only produced results in the depth texture. In the end, in Renderdoc, I saw that the shader returned the right value for R but also an alpha value of 0. Even though the shader only had one float output and the color attachment had one color channel. I solved it by using glDisable(GL_BLEND) and re-enabling it after the shadow map is done

OK this seems weird because the cubemap is defined as R32F and the output from the shader is a single float so they should match. What GPU do you have? I use NVIDIA and I often see that subtle OpenGL spec issues are handled differently between NVIDIA and any other brand. You can try outputing (value, 0, 0, 1) from the fragment shader and see whether this allows you do get rid of the blend thing.

@@OGLDEV yeah indeed, definitely weird. I also have an Nvidia card, 4090, with Game ready drivers installed. I'll try to use the vec4 return value

@@OGLDEV So... The same thing happens on a Mac (OpenGL 4.1). If I change the output of the fragment shader from a float to a vec4 like you said it fixes the issue and I don't need to disable GL_BLEND. Thanks a lot!

Thanks for the feedback. I'm trying to follow up on your logic. You are calculating the dot product between the actual right vector and a constant up vector which is the cosine of the angle between them. This should be zero in most cases unless your right vector is "bad". Then you create a quaternion to pull the camera back to a natural position. Is my understanding correct? Is this an alternative solution to the SetUpVector function at the end of the video?

@@OGLDEV Exactly. This worked for me long time ago. I'm not a quaternion especialist although 😁

It's always good to have alternatives :-)

You're welcome :-)

What's the nature of the distortion? What's the contents of the projection matrix?

@OGLDEV basically, when the object goes to the side of the viewport, it gets heavily distorted, i tried reducing the fov but that doesn't seem to work.

OK, and how does the projection matrix looks like? Try using a square window do disable interference of the aspect ratio.

@@OGLDEV sorry for being late to reply, but the projection matrix looks like this: 1/ (aspect * tan(halfFOV)), 0, 0, 0 0, 1 / (tan(halfFOV)), 0, 0, 0, -((far_z + near_z) / (far_z + near_z)), -((2*far_z*near_z)/(far_z - near_z)), 0 0, 0, -1, 0 The fov is 45 degrees, while the near_z is 1.0f and the far_z is 1000.0f. Sorry for the congested typing.

@@OGLDEV sorry to bother you again, but have you a solution yet

You're welcome :-)

I'm not sure how common it is to implement LOD on a skinned mesh. Skinning is mostly for humans, creatures, mechanical devices, etc. LOD is for terrains. Anyway, skinning is implemented in the vertex shader so you can still have an LOD system using tessellation which comes after the VS. The geomipmapping algorithm which I presented in the terrain series is probably not a good match for skinning but need to think more about it.

@@OGLDEV ok thanks

You speak about totally different jobs, learning graphics (i.e. Vulkan / OpenGL / DirectX / Metal, and other low level technologies etc) will allow you to create game engines, improve performance of work on GPU (for games, film industry, artificial intelligence, etc), or even do scientific research on more beautiful or fast computer graphics algorithms. This path almost doesn't include any game development (i.e. making levels, game scripts, game balance, making story, etc), unless you make your own indie game from scratch. So if you seek the job of actually making games, you better learn the popular game engines, prototype your own small games, and seek a job position in game development. But if you're passionate about computer graphics, that's an awesome career path as well (and I enjoy every bit of it), it just that you won't probably make many games, but you'll be near the games, supporting them from low level

It's different but cpp is transferable

To expand on the other comments in this thread - if you plan to be a professional game developer then the question you need to ask yourself is: what's the most efficient way for me to develop this game which will provide the highest chances of completing the project successfully within the budget and time constraints? Since you (I guess) haven't completed any game yet either from scratch or using a game engine you may want to spend some time creating a prototype in both ways. I would assume that if you pick up your first Unity/Unreal tutorial you will be able to create a simple 3D game in a couple of weeks. As far as I know, most of the game developers these days choose this route. However, there are also many people who don't consider themselves great programmers and they go the game engine way simply to avoid the complexity of programming from scratch. If you do know OpenGL/Vulkan/DirectX you will have a unique advantage of being able to work on low level systems in companies that develop game using an in-house game engine and there are quite a few of those. Also try to avoid doing stuff from scratch more than once. You should build reusable components and systems that will provide you with an ever increasing library of code to help you jumpstart your next project more quickly. Bottom line, if you find graphics programming interesting then having knowledge of both OpenGL and one or two game engines will position you perfectly for many companies. If you are an indie game developer with a limited amount of time for your next game then a game engine is probably the safest bet. Hope this helps!

Thanks for all the people. All your answers helps me to get an good clarity. As of now, I have planned to spend time equally on learning both the opengl and the unreal engine. One small doubt, will the graphics of the game made using opengl, vulkan and directx will be equal to the graphics of unreal engine?. If not why plz since the game engine are made using these libraries right. Another one question, will AI replace the game programmers??? Once again! THANKS FOR ALL YOUR ANSWERS.

While Unreal engine is indeed based on an existing API which serves as its graphics backend, the difference is the level of techniques and algorithms that were implemented. You can watch videos from GDC on youtube where people talk about how they achieved the graphics that you see on today's AAA games. Regarding AI - I have no clue. Naturally some tasks can be done more quickly by AI but whether AI can replace the entire or most of the workforce? Can AI replace human creativity from this point forward?

You're welcome :-)

Thanks!

Thanks. The inverse of the camera position simply moves the camera to the origin. What about rotating the world so that the camera is aligned with the Z axis?

:-)

You're welcome :-)

Thanks! What we are trying to accomplish is the following: P*(V*(W*v)) where v is the local space position of the vertex. In this video we skipped W but this is the general idea. Instead of multiplying each matrix individually we combine them together to a single matrix. The way that the evaluation works and how the operators are executed in the statement 'm_persProjection * View' is that it's as if View is multiplied first by the vertex and then projection. So it's written like that but the evaluation is from right to left.

ok

You're welcome :-)

Thank you so much!

me2 ;-)

You're welcome :-)

Thanks!

You can structure a matrix using independent horizontal and vertical FOVs but you will probably end up with the two axes being not synchronized with one another - the image will be squeezed on one axis and stretched on the other. So the common practice is to define one FOV (can be either one) and basically match the other FOV dependent on that one through the aspect ratio. Let's assume that the FOV is 90 degrees. This makes tan(FOV/2)=1 and we can ignore this term in the matrix. Let's also assume that our window has a width of 2000 and a height of 1000. So the aspect ratio is 1/2. Now let's see what happens to the point (2,2,2). The matrix has 1 in cell [0][0] so x remains 2 and after perspective division (2/2) we get 1. This means that the point is exactly on the righthand side of the (-1,-1) to (1,1) square which is what eventually gets mapped to the viewport. What about y? In cell [1][1] we get 2 (1/ar) so after multiplying we get 4 and after perspective division we get 2 which is way out of that normalized square. This means that to get to the top of the square and not get clipped the y has to be 1 (when Z is 2). So the bottom line is that when Z=2 the visible horizontal range is -2 to 2 while the vertical range is only -1 to 1. This matches the fact that the height of the window is half the width. We simply have more pixels from left to right than we have from top to bottom.

OK I see the source of the mixup. Looks like my latest code has changed since the time of the video and my initial reply refers to the latest code. The aspect ratio used to be the width/height and it was multiplied by 'd' in cell [0][0] (that's the first cell along the diagonal which is multiplied by x). Now the aspect ratio is height/width and it goes to the denominator of cell [1][1] (the second cell along the diagonal which is multiplied by y). If we use a horizonal field of view we indeed get the range of -old_ar to +old_ar (which is -2 to 2). Now we use a vertical field so the same range is actually -1/new_ar to +1/new_ar which is actually the same.

@@OGLDEV I get it now thank you

np

@@OGLDEV i am so sorry if I am taking too much of your time. But after reading your second reply I got a bit confused again. I am just going to say what i think makes sense and if you can just tell me what is wrong with that approach i would forever be greatful. Let's say we are using the x/y aspect ratio, and in the [1][1] we simply have 1/tan(vfov/2) which makes complete sense it puts y values in -1 to 1 interval. Now for the x if i use horizontal instead of vertical (like you mentioned assume that they are matched) as you just confirmed i would get the interval between -ar to ar and then we got the division by ar which puts it into -1 to 1 interval. So why not use the horizontal instead then? If this works How does the vertical even work?

Thanks!

Thanks! Good question. The simple answer is that we ignore the bone transformations. This algorithm doesn't provide a good solution when it comes to normals. Some people apply the same bone transformation matrix on the normal. Depending on the model and the animation, this may provide better results than ignorning the normal. You can also add geometry shader and recalculate the normal based on adjacency info.

Got it! Thanks!

You're welcome :-)

Glad you liked it!

I solved sudo apt install libmeshoptimizer-dev

Yes, when using a right handed coordinate system. I'm using left handed so the z is positive.

You mean VkDevice? All the Vulkan handles are actually pointers so you simply pass them around as is. The device itself is not copied.

You're welcome!