Clone the sources: git clone --recurse-submodules github.com/emeiri/ogldev.git If you want to get the same version that was used in the video you can checkout the tag 'TUT_54_ENDLESS_GRID'. Note about the white dots: in the area locked between two horizontal lines the result of 'mod(WorldPos.z, gGridCellSize) / dFdy(WorldPos.z)' is 1 or more which leads to a black color. This is explained in the video. In the area locked between two vertical lines the result of 'mod(WorldPos.x, gGridCellSize) / dFdx(WorldPos.x)' is one or more for the same reason. The dudv vector combines all the derivatives on all directions and components into a single vec2 and using the max2 function on that vector returns the maximum of the two components. This means that along a horizontal line we will get the the result from the X derivative of X and along a vertical line we will get the same with Y. So we end up with a black color on both. Only in the places where they meet we get a zero alpha which leads to white.
@OGLDEV, really enjoyed getting this up and running. I have 3 questions. 1) I added 2 more LOD's for a smoother transition but I'm not sure if I did it correctly Is that possible? and 2) I always use anisotropic filtering for the textures on the cpu side, but since we're not dealing with any textures here how can one write a anti-aliasing feature in the fragment shader? 3) It turns out I messed up the 1st time , and some reason I had to (1.0 - worldPos.z) in order to get the texture colors to be the same as yours @ 4:47. Why is mine flipped if I don't subtract 1 from the z axis? After fixing these issues, it's just like yours now =)
1. Perhaps the LODs are too far? Change log10 to a base 2 log and fix the cell size scaling accordingly. 2. For a pseudo anti aliasing the fragment shader I think you will need to do the same calculation on a quad of pixels around the current pixel and average them out. Something like PCF. 3. Right vs Left handed coordinate system?
i literally finished my own (probably subpar) implementation yesterday of a grid yesterday! yours looks much better though, so i look forward to implwmenting it! :)
@OGLDEV, oh boy terrific upload. 👍👍 Years ago I did a crappy version of this and I always enjoy alternate ways to figure out a solution. This is great timing because I'm trying to understand rayleigh scattering and mie scattering on the side and for an endless grid like this I can really use, Thank you! 👏👏
Maybe a dumb question: How much better is this compared to redering a bunch of lines for the grid (not including the finer LOD)? What would be advantages / disadvantages of either approach?
I think that the 'bunch of lines' rendering adds more complexity on the application side. You can't just stick the grid to the camera as we do here because it will look like nothing is moving. So you probably need to implement some sort of a grid of grids in the actual world position and make sure you only render the ones that are infront of the viewer. Constantly intersect the grid with the view frustum. Perhaps there's a better way. Need to do some research. Even with the 'bunch of lines' rendering you may still want to pick up some stuff from this technique - alpha blending, etc.
What do you mean exactly? You can use this tutorial for the visualization of the grid and I have a couple of videos on 3D picking (selecting an object with the mouse). But Blender has tons of features.
Would it be more performant to render an actual grid of vertices in GL_LINES instead of doing per-pixel calculations? One can make the grid mesh follow the camera on axis at major grid increments so it appears endless. Major grid increment line sizes can be modified with glLineWidth etc.
The grid mesh would have to change depending on the distance from the camera and it would get very large. Imagine several thousand vertices on the horizon. At a certain distance and viewing angle you're drawing more vertices than there are pixels on the screen. And all of these millions of vertices have to be stored in a vertex buffer on the GPU.
@@Kobold666 Ah yes, you're right. It would have to be a size limited grid, wouldn't look the same as the technique discussed in the video. Only works well with limited camera angles as you've pointed out. Like 2D editors or top-down 3d perspectives 👍
You can use tessellation for handling the LOD - increase tessellation level close to the camera. Not sure about the overall performance, though. Need to measure and compare...
If you have time, please do tutorials on 3d gizmos such as translate, rotate, scale and then saving the model's new transforms to disk and loading them from disk. This together with object picking and endless grid will start becoming a 3d game engine.
Due to lack of time I've made a "strategic decision" not to implement a full blown game engine and instead, focus on rendering and gameplay techniques. My plan is to increase the usage of Blender as an instrument to cover for missing features. For example, design the entire scene in Blender and do the rendering and gameplay in C++/OpenGL outside of Blender. I do have a couple of videos on object picking because this indeed is a good example of a technique that can be implemented independently.
@@OGLDEV I totally understand and support your decision. I was inspired by games like cities skylines 1 and 2 and there in-game asset editor. It would be helpful if translate, rotate and scale gizmos were available in the game itself. I suddenly became curious about how to implement only the gizmos and there functionality in your opengl renderer because of the endless grid video. Also, thinking about rotating each bone of a skeleton to pose the model in-game using the gizmos.
You can render the gizmos procedurally as a set of lines but perhaps it will be better to prepare a model in Blender and then render them last with depth test disabled. The regular picking technique should work the same to detect that the mouse touches the gizmo.
Omg man you took too long to explain this topic, and is a basic one, search for grid opengl in TH-cam and nothing useful shows, but well at least now we have your video
Clone the sources:
git clone --recurse-submodules github.com/emeiri/ogldev.git
If you want to get the same version that was used in the video you can checkout the tag 'TUT_54_ENDLESS_GRID'.
Note about the white dots: in the area locked between two horizontal lines the result of 'mod(WorldPos.z, gGridCellSize) / dFdy(WorldPos.z)' is 1 or more which leads to a black color. This is explained in the video. In the area locked between two vertical lines the result of 'mod(WorldPos.x, gGridCellSize) / dFdx(WorldPos.x)' is one or more for the same reason. The dudv vector combines all the derivatives on all directions and components into a single vec2 and using the max2 function on that vector returns the maximum of the two components. This means that along a horizontal line we will get the the result from the X derivative of X and along a vertical line we will get the same with Y. So we end up with a black color on both. Only in the places where they meet we get a zero alpha which leads to white.
@OGLDEV, really enjoyed getting this up and running. I have 3 questions. 1) I added 2 more LOD's for a smoother transition but I'm not sure if I did it correctly Is that possible? and 2) I always use anisotropic filtering for the textures on the cpu side, but since we're not dealing with any textures here how can one write a anti-aliasing feature in the fragment shader? 3) It turns out I messed up the 1st time , and some reason I had to (1.0 - worldPos.z) in order to get the texture colors to be the same as yours @ 4:47. Why is mine flipped if I don't subtract 1 from the z axis? After fixing these issues, it's just like yours now =)
1. Perhaps the LODs are too far? Change log10 to a base 2 log and fix the cell size scaling accordingly.
2. For a pseudo anti aliasing the fragment shader I think you will need to do the same calculation on a quad of pixels around the current pixel and average them out. Something like PCF.
3. Right vs Left handed coordinate system?
Nice job! I tried doing a grid myself a couple of week ago and my results were sooo bad. Now I can give it another shot, thanks! :)
You're welcome! Good luck :-)
As usual great video. Btw I learned OpenGL thanks to you!
Glad I could help!
Very nice job. I will try to implement the endless grid, Gracias!
De nada!
i literally finished my own (probably subpar) implementation yesterday of a grid yesterday! yours looks much better though, so i look forward to implwmenting it! :)
Have fun!
Awesome, I’ll implement one in my engine soon
Nice!
Tron Legacy soundtrack starts playing in my head*
This video is sponsored by Jeff Bridges.
@@OGLDEV 😄😄🔥
@OGLDEV, oh boy terrific upload. 👍👍 Years ago I did a crappy version of this and I always enjoy alternate ways to figure out a solution. This is great timing because I'm trying to understand rayleigh scattering and mie scattering on the side and for an endless grid like this I can really use, Thank you! 👏👏
You're welcome :-) Good luck!
Maybe a dumb question: How much better is this compared to redering a bunch of lines for the grid (not including the finer LOD)? What would be advantages / disadvantages of either approach?
wondering this as well.
I think that the 'bunch of lines' rendering adds more complexity on the application side. You can't just stick the grid to the camera as we do here because it will look like nothing is moving. So you probably need to implement some sort of a grid of grids in the actual world position and make sure you only render the ones that are infront of the viewer. Constantly intersect the grid with the view frustum. Perhaps there's a better way. Need to do some research. Even with the 'bunch of lines' rendering you may still want to pick up some stuff from this technique - alpha blending, etc.
@unqualifiedgamer6252 See response above.
Nice results. Thanks.
You're welcome!
Can u make tutorial on 2d grid like node editor of blender
What do you mean exactly? You can use this tutorial for the visualization of the grid and I have a couple of videos on 3D picking (selecting an object with the mouse). But Blender has tons of features.
Would it be more performant to render an actual grid of vertices in GL_LINES instead of doing per-pixel calculations? One can make the grid mesh follow the camera on axis at major grid increments so it appears endless. Major grid increment line sizes can be modified with glLineWidth etc.
The grid mesh would have to change depending on the distance from the camera and it would get very large. Imagine several thousand vertices on the horizon. At a certain distance and viewing angle you're drawing more vertices than there are pixels on the screen. And all of these millions of vertices have to be stored in a vertex buffer on the GPU.
@@Kobold666 Ah yes, you're right. It would have to be a size limited grid, wouldn't look the same as the technique discussed in the video. Only works well with limited camera angles as you've pointed out. Like 2D editors or top-down 3d perspectives 👍
You can use tessellation for handling the LOD - increase tessellation level close to the camera. Not sure about the overall performance, though. Need to measure and compare...
Ok thanks...more modern OPEN GL... 👍
More to come!
If you have time, please do tutorials on 3d gizmos such as translate, rotate, scale and then saving the model's new transforms to disk and loading them from disk. This together with object picking and endless grid will start becoming a 3d game engine.
Due to lack of time I've made a "strategic decision" not to implement a full blown game engine and instead, focus on rendering and gameplay techniques. My plan is to increase the usage of Blender as an instrument to cover for missing features. For example, design the entire scene in Blender and do the rendering and gameplay in C++/OpenGL outside of Blender. I do have a couple of videos on object picking because this indeed is a good example of a technique that can be implemented independently.
@@OGLDEV I totally understand and support your decision. I was inspired by games like cities skylines 1 and 2 and there in-game asset editor. It would be helpful if translate, rotate and scale gizmos were available in the game itself. I suddenly became curious about how to implement only the gizmos and there functionality in your opengl renderer because of the endless grid video. Also, thinking about rotating each bone of a skeleton to pose the model in-game using the gizmos.
You can render the gizmos procedurally as a set of lines but perhaps it will be better to prepare a model in Blender and then render them last with depth test disabled. The regular picking technique should work the same to detect that the mouse touches the gizmo.
@@OGLDEV Thank you for the ideas.
You're welcome :-)
Omg man you took too long to explain this topic, and is a basic one, search for grid opengl in TH-cam and nothing useful shows, but well at least now we have your video
Thanks, I just recently read an article in my Vulkan book which explained how to do it...
For some people long and slow is a better way of learning :)
I think he just meant it took ages to finally get around to making this video.... not that the explanation took too long
@@StevenMartinGuitar you’re probably right, it could be read both ways - gotta love text! :D thanks for the perspective!