Видео

You're welcome! Graphics existed before the programmable pipeline. In the case of OpenGL there was the deprecated pipeline with an API which supported a very specific type of lighting model, fog, etc. Before that sw rasterization was the way to go (Doom, Quake, etc). I'm not an expert on the PS1 but from what I know it had a GPU which provided various rendering effects which allowed you to program very close to the HW. I imagine it was similar to the idea of the deprecated GL pipeline even though the API was probably somewhat different.

Glad it was helpful!

Texture coordinates are explained in tutorial #16 (texture mapping). Since TexCoord0 is a vec2 then it is indeed equivalent to TexCoord0.xy. I guess I was a bit explicit here.

Simply use GLFW... ;-)

@@OGLDEV No doubt that is simpler. But I prefer to code what I'm able. GLFW is nice but it does a lot I don't need. I don't find creating a window or handling input prohibitively difficult in Linux or Windows. I will say importing all the GL functions manually is pretty unpleasant though. So I am currently using GLAD. At least until I figure out what I need and don't. It's amazing how much simpler OGL is compared to Vulkan. Way nicer to just try stuff out and experiment with.

I usually go with simpler if it works out of the box and coding it myself does not provide an actual benefit. That's why I use GLFW, GLEW, Assimp and STB. I coded my own math functions for the tutorials in order to explain 3D math but on a real project I wouldn't mind using GLM.

@@OGLDEV That's reasonable. It's personal preference.

Sure

You're welcome! The endless grid technique doesn't deal with height generation. It uses the distance from the camera to generate a dynamic grid on a flat square. So it's not equivalent to any terrain rendering algorithm.

@@OGLDEV Thanks for your explanation, now I understand. and what is de purpose to have and endless grid?

Visual debugging, and for implementing a dynamic grid for stuff like Blender, Unity, etc.

Wow, I didn't know that. So tragic. Such a loss.

I haven't measured myself but since this is such a popular technique I assume that there is an increase in performance. Note that the improvement highly depends on the size of the workload and the amount of pressure it puts on the GPU as well as the specifications of the machine. So for each use case you will get a different result.

​@OGLDEV completely agree with the answer.

Thanks :-)

np...

Shader programs and OGL objects are orthogonal in terms of initialization. You just need to make sure by the time you call glDraw* that everything is initialized and bound.

You mean the sampler ID that goes to the shader? I'm assuming that in a real world app you will be switching multiple textures so I show all the steps even if something is done by default.

Sorry, I'm not familiar with h264 in Vulkan.

Looks correct.

@@OGLDEV Thanks, your tut cleared up lots of things. Probably the clearest and most complete programming tutorial of skel animation I've seen online. Cheers!

Thanks!

It's actually not that advanced. I'm using the "3D Graphics Rendering Cookbook" as a guide for this series and this topic comes after textures and a few renderer restructuring.

Good luck! You've got a new sub!

@@OGLDEV thanks so much. I think my channel is doing well 🥳

Thanks! Welcome aboard!

I haven't tested the perf limits of that implementation. If you plan to render lots of sprites simply make sure that you have a large enough vertex buffer so that you can render all of them in one draw call and then you'll be fine. My PC specs: Core-i9, GTX1650, 16GB ram.

I don't know about 1.3.296. I'm using 1.3.290 and they work fine. Maybe try to downgrade. Is there a previous verison where you know they were working?

@@OGLDEV Turned out to be user error, or the debugger wouldn't report the instance not being destroyed. And it wouldn't report anything missing unless something first has been made, such as a physical device not being destroyed correctly.

Great!

Thanks!

Always welcome :-)

Thank you so much!

Glad you enjoy it! 😁

The original condition was -Wc<=Xc<=Wc. To calculate Xc we apply the projection matrix on the view space vector. Otherwise moving the camera will have no effect. So we have to use p_view and not p_world on all the calculations. This is just to show the transformations that the position has to go through. To avoid transforming p4d to view space (as we do in the first method) we calculate the clip planes based on the view-projection matrix. This is why it is more optimized.

​@@OGLDEV Thank you for the quick answer! Sorry again, so: The idea is not avoiding multiplying vertex by a matrix each frame? In fact, in 10:10 (method 1) you do that, and 18:20 (method 2) you don't do that. Method 1: p4D = VP * vec4(p, 1.0) Method 2: p4D = vec4(p, 1.0) Method 1: Inside = p4D.x <= p4D.w && p4D.x >= -p4D.w && ... Method 2: Inside = dot(leftClipPlane, p4D) >= 0 && dot(rightClipPlane, p4D) <=0 && ... So p4D (in method 2) is in World Space (you didn't multiply it by any Matrix). That's why I mean that must be 'p_world' and not 'p_view', because you never multiplied 'p' by any matrix before. (assuming 'p' in World Space, and not in Local Space obviously). Also, your Update of Frustum Planes take ViewProjectionMatrix as parameter: void Update(const Matrix4f& ViewProj) { ViewProj.CalcClipPlanes(m_leftClipPlane, ...); } Anyway, I understand that the proof in method 2 is correct, and the dot_product(p_view, row1 - row4) is fine, because row1 and row4 come from a ProjMatrix transformation (and not ViewProjMatrix). But the question is in contrast to the code. Thanks again!

Yes, the idea is to optimize away the matrix multiplication. But if what bothers you is the slide in 21:43 then at this point we are looking at the naive method of going from view to clip space. And then we incorporate that knowledge into the calculation of the clip planes so we don't need to do the matrix multiplication. So the slide doesn't indicate what the code is doing, just the rational of how we get there.

I'll check it out. Thanks for the tip.

@@OGLDEV in AlmondEngine it's setup with msvc and also completely seperately with CMake, so it could be working within minutes.. microsoft has a tutorial on how to set it up, and in CMake just include the "include and share" directories, the triplet is automatic to the OS and system eg x64... on linux I had to install libs in classic mode before cmake could copy them over, but you can uninstall once they do.. it creates a vcpkg in your project directory and when you remove items and build it'll uninstall them also. it builds and copies the dll, libs, at runtime into the bin folder also, It's the only way to code now.

@@OGLDEV Search vcpkg manifest mode tutorial

@@OGLDEV there are other package managers as well eg Conan

@@OGLDEV ruclips.net/video/0h1lC3QHLHU/видео.html

You're welcome!

Now you found it!

True, same for VAO.

You're welcome! Do you mean that when the camera is moving and the light doesn't the shadows move instead of being stationary?

@OGLDEV thanks for the reply!) No, when the light is stationary, and the camera rotates, everything works fine, but when the object itself is rotated, the lit area on it, and the shadow rotate too, as if the light source has moved (which it didn't)

But if the object is rotated shouldn't it have an effect on the shadow? Unless the object is a sphere or something like that. If the light doesn't move the shadow WVP matrix and the shadow map should look the same. You can easily print the matrix and verify. The shadow map can be viewed in RenderDoc.

@OGLDEV I mean, it rotates like it's stuck to the object, as if it was just a texture. Logging data is a problem cause I'm using webgpu, it's not that straightforward, which is part of the problem)

Probably a bug in the construction of the shadow matrix. I'm not familiar with webgpu but this page provides some details on debugging with RenderDoc: eliemichel.github.io/LearnWebGPU/appendices/debugging.html

Quaternions are difficult to intuitively understand but afaik they are the best solution to all those camera rotation problems.

Thanks!

Thanks! So are you saying that it is actually better to run the algorithm in real time instead of using it as an offline tool to create a cubemap texture?

@@OGLDEV In the case of the 8k file yes! However, if the jpg file is 4k and lower the outcome may be different. Which I should've tested in advance I apologize.

Interesting, thanks.

@@OGLDEV another odd thing is I feel like the single jpg algorithm 'looks' better when looking up and down as opposed to the 6 file cubemap. However it could be all in my head.

Probably just a false impression. Since we are going through a cubemap texture anyway.

קרית חיים

@@OGLDEV טוב לדעת שיש לנו אנשים כמוך במדינה. תודה רבה אחי על התוכן הנהדר 🙏

בכיף!

You're welcome 😊

Merry Christmas! 🎄

@@OGLDEV I wish you a great year. 🍀🥳

Assuming that you are interested in learning a graphics API (because strictly for game development a game engine may be a better choice) then OpenGL is a good balance between low level and "developer friendly". Vulkan and D3D12 are very low level and move a lot of the driver work over to you. Theoretically it should provide performance improvement but you need to know what you're doing and how to optimize. OpenGL allows you to build almost any kind of renderer but the driver still takes care of a lot of stuff for you.

It must be incredibly hard and frustrating learning vulkan (or D3D12, Metal) if you don't have a previous knowledge of any Graphics API first. I think it's more human-friendly to learn OpenGL ES 1.1 to learn the basics, then OpenGL ES 3.0 and finally (and if your app/game has a cpu bottleneck) Vulkan. As far as I know OpenGL ES 3.0 has some advantages than OpenGL, it runs on Android and with ANGLE as a Renderer, it translates OGL calls to Vulkan, D3D and Metal

I recommend studying OpenGL before Vulkan. I'm not experienced with ES but I guess it should serve the same function of providing a 3D foundation as well as 3D math which will be useful for Vulkan as well.

You're welcome! I'll probably do that later in the series. I'm following a book which came out prior to the new api but I'll find a spot for it.

Thanks for the feedback. Why is this more efficient? You have separate functions for pitch and yaw so you call angleAxis twice.

@@OGLDEV The implementation in the video creates 2 quats as well one with the constructor that takes in a vector and one with the lookat function, I might be wrong but I thought my way could be more efficent because of the way I use quats to get the right vector and simply rotate around that.

The quaternion in the constructor is called only once so it doesn't really matter. I'm making the comparison with my CalcCameraOrientation() which creates a single quaternion from the change on both X and Y and multiplies it by the orientation matrix.

@@OGLDEV calcameraorientation by itself does not really work though, It calls SetUpVector which creates another quat.

True. This is to reset the orientation of the camera so that it doesn't tilt from side to side (supporting only yaw and pitch, avoiding rolling). Did you have this problem? How did you solve it?

Reminds me that I wanted to try pl_mpeg

I've added this to the todo list. I have to admit that I'm not familiar with this so will require some research to implement.

@@OGLDEV I understand. Unfortunately ffmpeg examples are pretty rare and most of them do not decode to video memory but rather to system memory and then copy back to the GPU which is very inefficient but simpler I guess. Thanks for looking into it.

Glad it was helpful! Thank you for your continued support 😊

To get 10 months of early access (per the "Officer in the 3D underground" tier on Patreon) just send me your email.

I would love to make a D3D11 series. Unfortunately I don't have the time for it...

Perhaps the usage of 'R' is a bad naming choice because it confuses with the Greek rho. The docs indeed do the square root without Z.

@@OGLDEV You're just picking the wrong lengths/ratios of the right-sided triangle when calculating the tangent of the angle. Tangent = opposite side / adjacent side. But you did hypotenuse / adjacent.. *And we all thought that the part @**9:42** was the confusing part.* 🙂 fun.. It really _is_ confusing with all the axis swapping and/or negating. It all looks the same, and it makes you simple. I had to do it too in a project, and i used a matrix to convert the values (looks cleaner?). But it didn't work the first time 😄 because of confusion(s) => mistakes.

sqrt(x^2+y^2) is the length of the projection of line on the XY plane. What I did is Z/sqrt(x^2+y^2) which is the arctan of (90-theta) instead of theta as it appears in the diagram. But I guess it makes sense because we get theta=0 on the XY plane (when Z is zero) and then v=0.5. When z=1 and sqrt(x^2+y^2)=0 we get theta=PI/2 and then v=0. When z=-1 and sqrt(x^2+y^2)=0 we get theta=-PI/2 and then v=1. So I was confused by then wikipedia diagram /equations which demonstrates the formal picture but for the cubemap case we should actually draw theta "below" the line rather than above it.

@@OGLDEV You debugged it afterall. ;-) In any case, this video is of good help for me. I am writing a little program to make a flat Earth. A friend wants to decorate a wall with a map of our planet, but without any distortion of distances (so, not using any of the usual map projections). Now i don't have to think so much anymore about how to tackle that problem in the calculations. 👍

Yes, your comment gave me the motivation. Good luck with the project!

You're welcome! Thanks for the feedback, hopefully at this stage people know that every input attribute in the fragment shader is the result of an interpolation of a vertex shader output variable.

Glad that the tutorials were helpful 😀

I think it is a much nicer read than the spec. The spec is just like any other spec - contains all the details and makes it difficult to see the big picture. The book is more condensed and makes it easier to study a specific topic. I try to read the relevant chapter before every tutorial.

Another great upload. But with all due respect, the title to this video tutorial should be Equirectangular Cubemapping!

Thanks! I think the original title will bring in more views... RUclips now allows you to experiment with multiple thumbnails and see which works best but you are still limited to a single title at a time. Maybe in the future I'll try a different title and see if it works better :-)

Usually the heightmap doesn't include water. You decide the height of the water and then build a separate mesh for the water on top of the "ground".

Thanks! I was thinking of taking the same approach.​@@OGLDEV

Great! You can see my water demo which is based on the tutorial by @ThinMatrix here: ruclips.net/user/shortsglBziimIN14?feature=share. See the vid description for the source. The water mesh in this case is just a rectangle but there are more advanced approaches.

What errors exactly?

Thanks! There are many approaches to handling shadows from multiple light sources. The basic method is indeed to create several textures and render into them. You can use the geometry shader to render into multiple textures instead of doing a multi-pass on the application level. You can use a texture array for holding multiple textures. I haven't done much optimization on this topic so I guess you'll need to do more research. The following contains interesting info on multiple shadows in Doom: www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/#shadow-map-atlas. I hope to cover this topic at some point...

@@OGLDEV thank you so much

Thanks!