LITERALLY!! I've been writing a 3D engine for one of my college courses over the past few months and I saw him talking about 3D and texture coordinates and things and I was like KING KING KING KING We love u Garbaj
Started learning OpenGL 3 months ago with the goal of creating a UI library and then a game engine. Only now I think I have a good enough grasp on it to start working on a real project rather than experiments. It's very fun to mess around with and the performance you get in your own engine is absolutely insane. I can draw 500 cubes to the screen with lighting and still have 4000fps (literally) easy
@@handlemonium Both of you saying OpenGL isn't complex because something else exists that is even more complex is stupid af. Calculus isn't complex compared to phd mathematics, doesn't mean it's not hard for 99% of people.
For simple model importing, just look at obj. The ANSI version is rather trivial (and human readable), so all you have to do is read a text file. You can ignore stuff not implemented yet (like textures/UVs) and it should still work. But such experiments are great, considering all this knowledge (math and brain mush included) can be used e.g. when working with vertex shaders, too.
Assimp (it's not an insult, it stands for Open Asset Import Library) is an alternative, too, if you want to have a look on how they do it for the most popular formats.
It's a good start and please don't give up on your engine. I have tried making graphics engines several times in the past, and they all ended up as abandoned projects in different stages of completion. But every time I got further and further. Only after I matured my software engineering skills enough that I was finally able to put things together in a way that they would not need to be tore down everytime I needed to add a new feature. Making your engine is a challenging and yet extremely rewarding process that will help you grow as a problem-solver. Keep at it mate :)
Tonight, I just made an even more basic 3D renderer using C# and WinForms. No OpenGL, no DirectX, not even a way to define a 3D point, and I "finished" it in about 3 days. It wasn't that hard, the only two difficult parts were getting a perspective projection matrix working and defining the 36 3D points and 12 triangles that made up the cube I rendered. This video was my biggest inspiration for the project, though I've been wanting to work on something like this for a few weeks now. Planning on using meshes and mesh files to speed up the process of the creating new 3D shapes, as well as on camera / object movement and rotation.
this is really wholesome and reminiscent to a graphics engine i tried to make a year ago, i managed to add basic 3D model importer for it and i gave up when i started dealing with basic lighting and shadows.
Abstraction is a double edged sword. It's nice when used by people who understand how it works, so they make utilities, but it's an ignorance pill when used by those who don't understand what lies beneath. Go back to the basics and build from there, then one day build your own abstractions, or use other peoples's.
@zeurumvr Yes, he referenced it, but what I believe you were saying is that making a graphics engine was *his* alternative to Unity, when it isn't actually an alternative for him, because he doesn't use it, and I believe still uses Godot, which has actually gotten far more funding because of Unity.
Coding in open GL is simultaneously the most interesting and infuriating thing I’ve done. But I’m super glad I’ve done it even if I do work with engines as you get a sneak peak out not just how render pipelines and lighting work but also the base starting level of every engine out there
Building an engine is an immense task. That's why Unity, Lumberyard, Frostbite, Creation, Unreal, etc. last so long. It's a crazy task to build a new one.
Lumberyard is a little weird to include since it's not really new. It started off life as a fork of CryEngine and Amazon had to pay Crytek for it to use it in house. Then parts of Lumberyard became Open 3D Game engine. I think a lot of in house game engines currently are modifications on already existing engines, than wholly from scratch implementations. Though their history is very much a secret to most.
These are general-purpose engines that try to solve every possible task and give abstractions over everything. To build a game from scratch with OpenGL is not as immense as you think. Only took me a couple months to get to a nice looking first-person shooter in OpenGL.
Depending on what type of game, it's not that big of a deal. Particularly for 2D games, making the engine is frequently simpler than making the game itself.
@@NEO97online Define a First Person shooter. Drawing Vertexes and Edges and rasterizing them with OpenGL communicating with your GPU, using a Modelimporter API is not building a game from scratch. Its like you saying you are building a car from scratch when you buy the engine, tires and glass, electronics from other people, the most complex things basically. And again, a 3d Model that resembles a weapon, a Rotation from the origin point and key input mapped to movement and velocity in world space is far from a FPS. Its basically a 3D Rendering but not a engine, you made a rendering engine. A true FPS has to have : Animations (good luck with adding complex ones which take bones into consideration), AI-Bots (good luck again, horrible to do from scratch).
Years ago I decided to make my own (bad) game and graphics engine. Though it wasn't great, it did allow me to learn a lot of about how these engines actually work, which made me both appreciate and understand tools like Godot more! Now, I can confidently work on some pretty advance tools, plugins and engine extensions, I better understand what can cause lag, and I overall feel more empowered having gone though that journey. Personally, I don't plan on revisiting such low-level things unless I have too, such as making a game for PSX or contributing to Godot, if ever I do.
I think it's good to make (or just try) to create your own game engine, to understand how to they work. I'm working in my very own GE intermittently for the last nine months based in a project from a JAM 12 years ago. I don't regret but it is too hard and still far to be "usable".
Maybe you could hook it to someone else's Editor and save yourself a hassle of building your own? ;-) All rendering would be calculated with your renderer!
@@theseangle Technically it should be possible but I didn't found any instructions on how to do that. You could just build it without any additional modules (without ANY of them!), generate a project, do some stuff and then use generated files in your own projects (all files are just plain text).
I started coding mine in 2007, made it as far as making a couple of 1-level demos, ported it to linux and then to PSP, all was going well then I started learning GLSL and that's what entirely killed my enthusiasm.
I feel this. Way back in the day I started with the NeHe (Neon Helium) OpenGL tutorials. Really old stuff now, but getting that first triangle, or spinning cube. It's always the same route it seems. :D Congratulations on the progress! Edit: Oh I can also greatly recommend looking into SDL2 if you haven't yet.
I recommend using assimp which supports a lot of formats and is easy to use. also look into basic shading (like phong and toon) as well as take a peak into deferred lighting. good work on the engine though, ive been personally expereimenting with vulkan which is like opengl but way more in-depth. My brain is toasted from it.
TH-cam recommended this video to me on the home page, I'm glad to see people trying to write graphics engines, I've been trying too. It's only just that I hoped it was DirectX
Good job for going so far ! I find the OpenGL documentation really hard to understand, but with a bit of reflection & some tutorials (from ThinMatrix on TH-cam especially) I managed to create a small game engine using opengl, it currently handles shaders, materials, lighing, instancing, input, etc. I am currently working on the audio using OpenAL but it might take some time 😌
Fun little bit of pedantry: it's not quite the basis of all 3D... but most 3D. There are voxels, point-clouds, signed-distance fields, et cetera... and if you are rasterizing those, then yeah, you still end up back in a triangle (one that you might not even create manually), but if you're doing a path-tracer, and your scene is made of SDF objects or voxels, or whatever, then there's no triangle ... unless you are looking at a triangle... Regardless, glad to see more people getting their hands dirty with this stuff.
weird that I happened to see this while im taking my computer graphics course because this is exactly what ive done this semester, only got to the part where I can create artifacts and apply textures to them, and I dont see the class going any further.
Careful going down that rabbit hole. I spent 8 years doing this. Learned a whole lot, but I feel like I wasted a lot of time I could have spent on other projects.
Exactly. If you're planning a game and debating whether to create a game engine from scratch or use an existing engine, 100% go for an existing engine unless you're damn sure know what you're doing.
If you think OpenGL is hard, you never want to try Vulkan. Setting up OpenGL is trivial in comparison (except for loading functions but even then GLAD has you covered) as the driver and OS will initiate the context and client/server connection to the GPU. Vulkan requires creating instances, querying and selecting physical devices to create logical devices, manual memory management, graphics pipelines and caching and so many lower level details. But when done properly can result in extremely optimized and graphically impressive works like Doom Eternal.
This is always an awesome experience! Back in 2018-2019 I'd do a lot of different mini game engines with SDL/GLFW/etc, some using opengl, others directx, others libraries like SFML etc or event from zero like setting up a win32 layer and all. Nowadays I think I'd use RayLib. It's pretty compact and small and it has model/animation loading as well as many 3D methods to interact with models using raycasting which are useful and hard to implement if you're just starting to learn these things. Of course you won't have a lighting system buy you have all the model, shading and texturing loading with nice examples and you are left with the single problem of solving lighting youself instead of having to solve animations as well for example. Nice video!
This is completely out there, but I wonder if you could collab with Road to Vostok dev. He's also making a game by himself and as far as he told us in the dev videos, he was also rewriting stuff. Not sure if it was his own engine as well for the game because ~UNITY~ things, but something along those lines. And I find the idea interesting that the 2 of you suddenly come up with a basic yet robust new engine.
I made an engine in OGL for my CG fundamentals class and once you get the foundation done (texture loading, model loading, uniforms, eyc) it's really rewarding to add stuff later, like PBR and IBL. I'm trying to create a Vulkan game engine now. Vulkan is kicking my ass though.
if vulkan is kicking your ass, make sure you're learning from a good source! The top result on google recommends like 10 pages of logging before completing a basic program, that's how you know it's bad
Hi Garbaj, Welcome to the 3d world scene, good progress so far, it took me a while to understand some concepts, following along with a few different tutorials did not help either, some used old opengl ( fixed pipeline, which isn't bad if you want to play around with opengl to get a feel of things), others done modern opengl... and some done a mixture which raised soo many bugs and wasted time ::/ (below: lighting | under da hood | Framebuffer | ) I would say leave the lighting until you're 100% happy with everything else, it is just another resource that will be used when it is not needed in early stages, by all means you can start on it and not call it, but every time you'll go test out your work, you will always think "hmm What would it look like with light"... As far as "more under the hood", in what terms was you thinking, I believe there are some of us who "JUST'S NEEDS TO KNOW WHY" things work :) See below(bottom-ish maybe) if you're on a nix box ( linux machine ), you could play around with the fb ( framebuffer), you can even use python, to write out to it, so there is no GL/SDL/GLFW needed, as the FB file just contains pixel data informations < hope this helps a little. As for the under the hood here is some information that you may have seen already but could help others: you will have to look into reverse engineering your own work and putting many debug statements (a call function that = (printf HELLO WE ARE HERE 1.... 2.... 3->1000)), because each function you call with opengl will set certain registers on the CPU, to allow you to talk to the GPU, once communication has been made ( accepted ) more data is sent to the GPU that will set registers on the GPU ( as far as i know we can not view them) however we can view the memory/ stack to see what is pushed / popped. to get a grasp on how things may work, it will be beneficial for you to get a copy of your graphics architecture specs, that will sometimes display the registers so you can get an idea how information is passed through etc, if you have an AMD card then your luck has changed, because AMD does released their documents... Sooo many Documents, Perhaps ask chatGPT what type of documents that could help you out, anyways this messages has gotten rather long, good luck on your quest and keep us updated!! I hope that scratch gets itched ;-)
I too am trying to learn how to make one for paticular projects I have in mind. But Im wanting to use BGFX for one of them. I aim to make first 2 to run with low end hardware smooth as I can get it. Nice work sofar btw, hoping you start making it able to serve the games you want to do with it.
As someone learning software engineering I have to give you high praise on a job well done. By doing this you've shown your mettle with programming, you have a great future ahead of you sir garbage.
the challenge of this is a lot more than most would think, but as you mentioned most of the difficulty comes from the requirement of memorizing openGL, unless you use an already existing library but thats boring xD its all about the learning
Thats just how it is it becomes more complex but if you keep doing it eventually you will get the hang of it, some of it, its not only you I watch other people try and be disapointed how little they can do.
Thanks for not turn this into a "how I make a full feature game engine in a weekend because I'm genius and figure everything out in a tackle" video. For those who had tried graphic engine APIs knows how challenging is to make a textured cube on the screen.
It took me 1 year until I was capable to create a basic OpenGL renderer on my own (kinda), 1 more year until I was capable of doing PBR stuff. Recently, my engine ended up being toast but gonna fix it, trying something less hardcore. OpenGL has some quirks, and works in a black-box kind of way which is annoying and difficult to debug, but as a complete API it's good enough for an indie. Trying to learn Vulkan as well, but the gigantic amount of boilerplate code is overwhelming and I don't have anything working nicely on it. Other APIs are kinda single-platform (DirectX, Metal) or unfinished (WebGPU, SDL GPU API), so in the end OpenGL is still the best option for indies or beginners. You can kinda simplify the stuff with wrappers or libraries such as sokol-gfx (wrapper for OpenGL/WebGL/DirectX/Metal for C/C++) or raylib (mini-engine/library for C/C++). There are other options for other languages as well (there are several bindings for raylib for example)
I tried to do my own thing with graphics too, but in my case, wgpu with Rust lang. It was... a LOT of setup for basically nothing, and when it just abruptly stopped working, I was like "okay, FINE, let's just use Bevy." since Bevy has its own render pipeline and... basically everything I set up in wgpu is doable with Bevy in like ten minutes. But, that's just me... I thought about OpenGL, but its rust bindings are apparently subpar, and I didn't feel like learning C (or C++) so here I am. But all in all... SUPER cool to learn how graphics are done and how exactly the pipeline works so if I really need to get in there and tweak something, I'll at least somewhat know what I'm doing!
In first year at uni I decided it would be a good idea to apply math 101 and make a 3D engine from scratch without any OpenGL or DirectX. It worked some of the time and was dog slow. But it ran on Java for mobile in the age of dumb phones.
Hey garbaj, could you please make a tutorial about making a first person aiming system like the one seen in metroid prime hunters? this feature is also known as "deadzone aiming" or "free aiming"
This is quite an ambitious task, happy to see you got so far. Have you tried making your own game engine though? I ask because I heard about somebody (Codemonkey made a vid about him) who thought it was better to learn a coding language in and out before you make a game with it.
1. you learn both at the same time 2. 80% of what you learn about a coding language is going to be useless conjecture coming from some nerd's ego 3. opengl runs on 2000 threads at a time, but maybe 4x slower, than C / JS / Python, who run on 1-8 threads, but have limitless instructions where they run. Because the very nature of these languages is different, it helps to learn about the big picture even before you learn a single language.
I used OpenGL and built a little 2d framework, animating sprites, collision using a texture, etc... Had Ayala from Chrono Trigger running around, it felt good when it finally worked. That was before Unity broke the market and offered all features for free starting with Unity 5, gotta give them props for that. People forget Unreal was expensive as hell, most engines were, until Unity broke the dam, didn't mess with OpenGL since.
Correct me if I'm wrong, but OpenGL is as close to the metal as you can get. You can't write method to apply a texture to a surface yourself because the GPU is built to be more efficient at doing this code than a CPU code can
"Eventually you're going to want to add more detail." Yeah, I got as far as drawing a triangle, coloring the vertices, and making it spin. That was enough OpenGL for me lol :D
I guess everyone starting with OpenGL does that. I started with a triangle and then I made a cube and then I copied and pasted a random .gltf importer. After that I left the project. It has been 1 year. I will come to it soon. The hardest part in OpenGL for me is lighting. I can't predict what calculus is OpenGL doing on the background.
Talking to OpenGL is actually the easiest part of making a game engine. The hard part is building systems for meshes, textures, transforms, and scene trees around it in a way that is both robust and flexible at the same time. I'm at the point with my project where actual OpenGL code only makes up 10% of it, so I'm thinking about switching to Vulkan right away. It would actually make some things easier, since even the most recent OpenGL version is still somewhat stuck in the past conceptually.
All my OpenGL homies hate apple for deprecating it on all apple devices. But jokes aside, OpenGL is great for starting with your graphics programming adventure. I was a part of a team writing a custom engine and a game. We tried to force Vulkan at the beginning of the project to make a "modern" engine, but after a month of stuggling with Vulkan we rewrote the entire month's progress in OpenGL in one day and finished the engine (and a game on it) in the next two months. It was a great experience. To sum it up: OpenGL and chill, Vulkan and existential crisis.
I at first thought that you went with Vulkan which I would have applauded. I do recommend learning it or Webgpu since that api is a bit easier to learn than Vulkan but it is modern, cross platform and supports the web.
opengl should always be the first choice for a beginner, having such a large amount of control over the gpu is extremely stressful (even for experienced devs) and would be useless for a small project like this.
Fair but I also suggested webgpu as an alternative since In my opinion it is a good middle ground between control & simplicity. You can get a triangle on the screen fairly quickly without doing a lot of setup code but you'll also learn concepts and current best practices of how to interact with the api.
@@billymays8864 Or Xbox (though they require DX12 now, but that's easy enough to port or layer) - and Linux with DXVK (DX11 -> Vulkan with DXVK is often faster than native OpenGL on Linux).
Haha I just spent the last few months doing basically this, I made a pretty simple 2d physics engine with just opengl and glad, and just last week I ported it to 3d and added obj loading. It's fun! (and learnopengl is a godsend at the beginning)
I'm sure if you get to this project after a while you'll be 1000% better at it. Our brain needs time to understand things, sometimes, it's real time, like a month.
the most replayed part 💀
Garbaj, the collector. Collects the best 3d garbage there is for us ;)
you dont have to mention that- 💀
I saw the confusion meme and laughed then I saw the buttcheeks and comprehended.
💀
The internet has spoken
When a normal person sees you make you first triangle: 😪
When a graphics programmer sees you make your first triangle: Here you go king 👑
YOUR triangle ❣
use regl to get a triangle in one step instead of 10
saving instructions is important
@@willtheoct Looking into it, it automatically infers the vertex indices. Seems like an interesting library.
@@atomictravellerour triangle 🛠️⚒️
LITERALLY!! I've been writing a 3D engine for one of my college courses over the past few months and I saw him talking about 3D and texture coordinates and things and I was like KING KING KING KING
We love u Garbaj
When Unity fucked up so bad people rather reinvent the wheel.
There are no wheels in graphics programming.
@@colleagueriley860 autism
@@colleagueriley860it’s in reference to a very common idiom.
@@Kero-zc5tcThere are no idioms in graphics programming either, just tris
@@notactuallyarealperson2267 lolz
It's a good day when Garbaj uploads a video.
No
why does everyone comment this on any video ever
@@Solutra idk, lol
@@Solutraanoying init
HEELLL YEAAAHH ITS ALWAYS BETTER
Started learning OpenGL 3 months ago with the goal of creating a UI library and then a game engine. Only now I think I have a good enough grasp on it to start working on a real project rather than experiments. It's very fun to mess around with and the performance you get in your own engine is absolutely insane. I can draw 500 cubes to the screen with lighting and still have 4000fps (literally) easy
I love trying to make 3d engines. such a fun project to work on. great job!
until you get to clipping
@@vibaj16 the gpu does the clipping for you
Honestly, it just takes time to learn OpenGL and make complex stuff. I'd be happy if you continued on.
OpenGL is simple compared to other APIs, a tringle in pur Vulcan takes 2500 lines ...
Try Vulkan?
only if you like suffering that is@@handlemonium
@@handlemonium Both of you saying OpenGL isn't complex because something else exists that is even more complex is stupid af.
Calculus isn't complex compared to phd mathematics, doesn't mean it's not hard for 99% of people.
@@MohamedBenamer940 congratulations
For simple model importing, just look at obj. The ANSI version is rather trivial (and human readable), so all you have to do is read a text file. You can ignore stuff not implemented yet (like textures/UVs) and it should still work. But such experiments are great, considering all this knowledge (math and brain mush included) can be used e.g. when working with vertex shaders, too.
😮
Assimp (it's not an insult, it stands for Open Asset Import Library) is an alternative, too, if you want to have a look on how they do it for the most popular formats.
It's a good start and please don't give up on your engine. I have tried making graphics engines several times in the past, and they all ended up as abandoned projects in different stages of completion. But every time I got further and further. Only after I matured my software engineering skills enough that I was finally able to put things together in a way that they would not need to be tore down everytime I needed to add a new feature. Making your engine is a challenging and yet extremely rewarding process that will help you grow as a problem-solver. Keep at it mate :)
This was an interesting video to watch, thank you for making it! And also make sure to make videos of other such journeys of yours :)
Based vid for naming the dva mod. Yeah and something=something about graphic rendering
For the really crazy stuff you should give jdh a chance. This guy is doing some wild magic with his own engines, OSs and self made graphic cards
Tonight, I just made an even more basic 3D renderer using C# and WinForms. No OpenGL, no DirectX, not even a way to define a 3D point, and I "finished" it in about 3 days. It wasn't that hard, the only two difficult parts were getting a perspective projection matrix working and defining the 36 3D points and 12 triangles that made up the cube I rendered. This video was my biggest inspiration for the project, though I've been wanting to work on something like this for a few weeks now. Planning on using meshes and mesh files to speed up the process of the creating new 3D shapes, as well as on camera / object movement and rotation.
this is really wholesome and reminiscent to a graphics engine i tried to make a year ago, i managed to add basic 3D model importer for it and i gave up when i started dealing with basic lighting and shadows.
i love when people go back to absolute basics. Goes over my head more often than not, but it's incredibly fun to watch.
Abstraction is a double edged sword. It's nice when used by people who understand how it works, so they make utilities, but it's an ignorance pill when used by those who don't understand what lies beneath. Go back to the basics and build from there, then one day build your own abstractions, or use other peoples's.
@@TiaguinhouGFX oh, right on!
nice, Unity kinda shot themselves in the foot and it’s nice to see people’s alternatives!
Garbarj doesn't use Unity. He has always used Godot.
@@mostlime12195he refrenced it at the beginning
🤡🤡🤡
@@zeurumvr yes, but garbage was always a godot guy, if im not mistaken
@zeurumvr Yes, he referenced it, but what I believe you were saying is that making a graphics engine was *his* alternative to Unity, when it isn't actually an alternative for him, because he doesn't use it, and I believe still uses Godot, which has actually gotten far more funding because of Unity.
I love it when I randomly start thinking about something and its just happens the next day or two, I was wondering when you would post again.
Devs of the game Haydee knew exactly what the players want
Exactly! I love mysterious mazes filled with traps and deadly robots!
OUR QUEEN RETURNS!!!
(I don't mean to put pressure on you, these take a lot of effort to make! Just excited to see you in my subscriptions feed!)
Coding in open GL is simultaneously the most interesting and infuriating thing I’ve done. But I’m super glad I’ve done it even if I do work with engines as you get a sneak peak out not just how render pipelines and lighting work but also the base starting level of every engine out there
Building an engine is an immense task. That's why Unity, Lumberyard, Frostbite, Creation, Unreal, etc. last so long. It's a crazy task to build a new one.
Lumberyard is a little weird to include since it's not really new. It started off life as a fork of CryEngine and Amazon had to pay Crytek for it to use it in house. Then parts of Lumberyard became Open 3D Game engine.
I think a lot of in house game engines currently are modifications on already existing engines, than wholly from scratch implementations. Though their history is very much a secret to most.
These are general-purpose engines that try to solve every possible task and give abstractions over everything.
To build a game from scratch with OpenGL is not as immense as you think. Only took me a couple months to get to a nice looking first-person shooter in OpenGL.
Depending on what type of game, it's not that big of a deal. Particularly for 2D games, making the engine is frequently simpler than making the game itself.
first 3d game in 7 weeks using SetPixel, if it's just a height field, lighting and a couple of objects, it could take a weekend or two.
@@NEO97online Define a First Person shooter. Drawing Vertexes and Edges and rasterizing them with OpenGL communicating with your GPU, using a Modelimporter API is not building a game from scratch. Its like you saying you are building a car from scratch when you buy the engine, tires and glass, electronics from other people, the most complex things basically. And again, a 3d Model that resembles a weapon, a Rotation from the origin point and key input mapped to movement and velocity in world space is far from a FPS. Its basically a 3D Rendering but not a engine, you made a rendering engine. A true FPS has to have : Animations (good luck with adding complex ones which take bones into consideration), AI-Bots (good luck again, horrible to do from scratch).
Years ago I decided to make my own (bad) game and graphics engine. Though it wasn't great, it did allow me to learn a lot of about how these engines actually work, which made me both appreciate and understand tools like Godot more! Now, I can confidently work on some pretty advance tools, plugins and engine extensions, I better understand what can cause lag, and I overall feel more empowered having gone though that journey.
Personally, I don't plan on revisiting such low-level things unless I have too, such as making a game for PSX or contributing to Godot, if ever I do.
nice to see you back
facts
Yooo he uploaded!! Glad to see you've been keeping up with programming.
I think it's good to make (or just try) to create your own game engine, to understand how to they work. I'm working in my very own GE intermittently for the last nine months based in a project from a JAM 12 years ago. I don't regret but it is too hard and still far to be "usable".
Maybe you could hook it to someone else's Editor and save yourself a hassle of building your own? ;-)
All rendering would be calculated with your renderer!
Nah... Part of the fun is to do it everything. I don't care if noone else use it. And I'm not in a hurry.
@@igorthelightcan you for example take Godot and use its editor with your engine? Is it possible? How difficult is it?
@@theseangle Technically it should be possible but I didn't found any instructions on how to do that. You could just build it without any additional modules (without ANY of them!), generate a project, do some stuff and then use generated files in your own projects (all files are just plain text).
as an engine dev, you are in for a ride buddy.
I started coding mine in 2007, made it as far as making a couple of 1-level demos, ported it to linux and then to PSP, all was going well then I started learning GLSL and that's what entirely killed my enthusiasm.
Here's to hoping we'll see a custom game engine renaissance happen again
You know why I clicked. The video preview was on spot.
I feel this. Way back in the day I started with the NeHe (Neon Helium) OpenGL tutorials. Really old stuff now, but getting that first triangle, or spinning cube. It's always the same route it seems. :D Congratulations on the progress!
Edit: Oh I can also greatly recommend looking into SDL2 if you haven't yet.
took a computer graphics course in college and it was easily one of the hardest classes I've ever taken. Had to make a raycaster and it was very buggy
Being talented enough to attempt such feat.
Must be a good feeling.
I recommend using assimp which supports a lot of formats and is easy to use. also look into basic shading (like phong and toon) as well as take a peak into deferred lighting. good work on the engine though, ive been personally expereimenting with vulkan which is like opengl but way more in-depth. My brain is toasted from it.
TH-cam recommended this video to me on the home page, I'm glad to see people trying to write graphics engines, I've been trying too. It's only just that I hoped it was DirectX
Good job for going so far ! I find the OpenGL documentation really hard to understand, but with a bit of reflection & some tutorials (from ThinMatrix on TH-cam especially) I managed to create a small game engine using opengl, it currently handles shaders, materials, lighing, instancing, input, etc. I am currently working on the audio using OpenAL but it might take some time 😌
So this is what you have been up to. Good to finally hear from you mate
i think that's a huge first step
this guys is REALLY good, especially his SDL2 tutorial (which in general is a nightmare to find on the internet)
Fun little bit of pedantry: it's not quite the basis of all 3D... but most 3D. There are voxels, point-clouds, signed-distance fields, et cetera... and if you are rasterizing those, then yeah, you still end up back in a triangle (one that you might not even create manually), but if you're doing a path-tracer, and your scene is made of SDF objects or voxels, or whatever, then there's no triangle ... unless you are looking at a triangle...
Regardless, glad to see more people getting their hands dirty with this stuff.
1:25 im glad you know your audience
weird that I happened to see this while im taking my computer graphics course because this is exactly what ive done this semester, only got to the part where I can create artifacts and apply textures to them, and I dont see the class going any further.
Good to see you again, Garbaj!
This video was cute and it made me smile.
And then I realized it was a Garbaj video, dude, your stuff is nice, thanks!
Careful going down that rabbit hole. I spent 8 years doing this. Learned a whole lot, but I feel like I wasted a lot of time I could have spent on other projects.
Exactly. If you're planning a game and debating whether to create a game engine from scratch or use an existing engine, 100% go for an existing engine unless you're damn sure know what you're doing.
If you think OpenGL is hard, you never want to try Vulkan. Setting up OpenGL is trivial in comparison (except for loading functions but even then GLAD has you covered) as the driver and OS will initiate the context and client/server connection to the GPU. Vulkan requires creating instances, querying and selecting physical devices to create logical devices, manual memory management, graphics pipelines and caching and so many lower level details. But when done properly can result in extremely optimized and graphically impressive works like Doom Eternal.
Everyone has to start somewhere, but not everyone will. You did, so good job
This is always an awesome experience! Back in 2018-2019 I'd do a lot of different mini game engines with SDL/GLFW/etc, some using opengl, others directx, others libraries like SFML etc or event from zero like setting up a win32 layer and all.
Nowadays I think I'd use RayLib. It's pretty compact and small and it has model/animation loading as well as many 3D methods to interact with models using raycasting which are useful and hard to implement if you're just starting to learn these things. Of course you won't have a lighting system buy you have all the model, shading and texturing loading with nice examples and you are left with the single problem of solving lighting youself instead of having to solve animations as well for example.
Nice video!
Raylib is my favorite game toolkit, hands down. Nothing else compares in its simplicity and ease of use, while still having a decent set of features.
The 3 month wait for a new garbaj video was worth it
This is completely out there, but I wonder if you could collab with Road to Vostok dev. He's also making a game by himself and as far as he told us in the dev videos, he was also rewriting stuff. Not sure if it was his own engine as well for the game because ~UNITY~ things, but something along those lines. And I find the idea interesting that the 2 of you suddenly come up with a basic yet robust new engine.
I made an engine in OGL for my CG fundamentals class and once you get the foundation done (texture loading, model loading, uniforms, eyc) it's really rewarding to add stuff later, like PBR and IBL.
I'm trying to create a Vulkan game engine now. Vulkan is kicking my ass though.
if vulkan is kicking your ass, make sure you're learning from a good source! The top result on google recommends like 10 pages of logging before completing a basic program, that's how you know it's bad
Hi Garbaj, Welcome to the 3d world scene, good progress so far, it took me a while to understand some concepts, following along with a few different tutorials did not help either,
some used old opengl ( fixed pipeline, which isn't bad if you want to play around with opengl to get a feel of things), others done modern opengl... and some done a mixture which raised soo many bugs and wasted time ::/ (below: lighting | under da hood | Framebuffer | )
I would say leave the lighting until you're 100% happy with everything else, it is just another resource that will be used when it is not needed in early stages, by all means you can start on it and not call it, but every time you'll go test out your work, you will always think "hmm What would it look like with light"...
As far as "more under the hood", in what terms was you thinking, I believe there are some of us who "JUST'S NEEDS TO KNOW WHY" things work :) See below(bottom-ish maybe)
if you're on a nix box ( linux machine ), you could play around with the fb ( framebuffer), you can even use python, to write out to it, so there is no GL/SDL/GLFW needed, as the FB file just contains pixel data informations < hope this helps a little.
As for the under the hood here is some information that you may have seen already but could help others:
you will have to look into reverse engineering your own work and putting many debug statements (a call function that = (printf HELLO WE ARE HERE 1.... 2.... 3->1000)),
because each function you call with opengl will set certain registers on the CPU, to allow you to talk to the GPU, once communication has been made ( accepted ) more data is sent to the GPU that will set registers on the GPU ( as far as i know we can not view them) however we can view the memory/ stack to see what is pushed / popped.
to get a grasp on how things may work, it will be beneficial for you to get a copy of your graphics architecture specs, that will sometimes display the registers so you can get an idea how information is passed through etc, if you have an AMD card then your luck has changed, because AMD does released their documents... Sooo many Documents, Perhaps ask chatGPT what type of documents that could help you out,
anyways this messages has gotten rather long, good luck on your quest and keep us updated!! I hope that scratch gets itched ;-)
I too am trying to learn how to make one for paticular projects I have in mind.
But Im wanting to use BGFX for one of them.
I aim to make first 2 to run with low end hardware smooth as I can get it.
Nice work sofar btw, hoping you start making it able to serve the games you want to do with it.
I think it's great that you've at least tried expanding your horizons, even if they didn't end up going that far. I know I wouldn't've done that :D
As someone learning software engineering I have to give you high praise on a job well done.
By doing this you've shown your mettle with programming, you have a great future ahead of you sir garbage.
Keep going on your game engine! :)
The bump in viewer retention when DVA is in the video 😂
It's good that you tried, but sounds like a nice project to come back to.
the challenge of this is a lot more than most would think, but as you mentioned most of the difficulty comes from the requirement of memorizing openGL, unless you use an already existing library but thats boring xD its all about the learning
most replayed part. not surprised.
Thats just how it is it becomes more complex but if you keep doing it eventually you will get the hang of it, some of it, its not only you I watch other people try and be disapointed how little they can do.
making a model loader is quite easy. just check the .obj file structure and then structure that data so that it fits your vertex specification.
Great explanation. Thank you
Thanks for not turn this into a "how I make a full feature game engine in a weekend because I'm genius and figure everything out in a tackle" video. For those who had tried graphic engine APIs knows how challenging is to make a textured cube on the screen.
It took me 1 year until I was capable to create a basic OpenGL renderer on my own (kinda), 1 more year until I was capable of doing PBR stuff. Recently, my engine ended up being toast but gonna fix it, trying something less hardcore.
OpenGL has some quirks, and works in a black-box kind of way which is annoying and difficult to debug, but as a complete API it's good enough for an indie.
Trying to learn Vulkan as well, but the gigantic amount of boilerplate code is overwhelming and I don't have anything working nicely on it.
Other APIs are kinda single-platform (DirectX, Metal) or unfinished (WebGPU, SDL GPU API), so in the end OpenGL is still the best option for indies or beginners.
You can kinda simplify the stuff with wrappers or libraries such as sokol-gfx (wrapper for OpenGL/WebGL/DirectX/Metal for C/C++) or raylib (mini-engine/library for C/C++). There are other options for other languages as well (there are several bindings for raylib for example)
I tried to do my own thing with graphics too, but in my case, wgpu with Rust lang. It was... a LOT of setup for basically nothing, and when it just abruptly stopped working, I was like "okay, FINE, let's just use Bevy." since Bevy has its own render pipeline and... basically everything I set up in wgpu is doable with Bevy in like ten minutes. But, that's just me... I thought about OpenGL, but its rust bindings are apparently subpar, and I didn't feel like learning C (or C++) so here I am. But all in all... SUPER cool to learn how graphics are done and how exactly the pipeline works so if I really need to get in there and tweak something, I'll at least somewhat know what I'm doing!
this channel name had me rolling
Awesome ! That looks great ! Keep it up !
Imagine the people that build *WHOLE OPERATING SYSTEMS!* that’s insane!
In first year at uni I decided it would be a good idea to apply math 101 and make a 3D engine from scratch without any OpenGL or DirectX. It worked some of the time and was dog slow. But it ran on Java for mobile in the age of dumb phones.
Great! Also, I started learning opengl a few days ago
I attempted to look into Vulcan but gave up.😅
I thought yesterday man its been a minute since I have seen a garbaj upload
Hey garbaj, could you please make a tutorial about making a first person aiming system like the one seen in metroid prime hunters? this feature is also known as "deadzone aiming" or "free aiming"
This is quite an ambitious task, happy to see you got so far. Have you tried making your own game engine though? I ask because I heard about somebody (Codemonkey made a vid about him) who thought it was better to learn a coding language in and out before you make a game with it.
1. you learn both at the same time
2. 80% of what you learn about a coding language is going to be useless conjecture coming from some nerd's ego
3. opengl runs on 2000 threads at a time, but maybe 4x slower, than C / JS / Python, who run on 1-8 threads, but have limitless instructions where they run. Because the very nature of these languages is different, it helps to learn about the big picture even before you learn a single language.
damn!! that's why it was the most replayed part
I used OpenGL and built a little 2d framework, animating sprites, collision using a texture, etc...
Had Ayala from Chrono Trigger running around, it felt good when it finally worked.
That was before Unity broke the market and offered all features for free starting with Unity 5, gotta give them props for that.
People forget Unreal was expensive as hell, most engines were, until Unity broke the dam, didn't mess with OpenGL since.
Lol nice job. I highly recommend binge-watching Ben Eater's series on building a graphics card using only breadboard connections.
when you realize 1:24 is the most replayed you start to see the game dev community true colors 💀
If you really wanna get intimate with the graphics pipeline, write a software renderer.
Keep up the good work man 🥳😄
I use Vulkan BTW
Although it is more verbose, in some things it looks much more logical, because it was originally created for modern video cards
Correct me if I'm wrong, but OpenGL is as close to the metal as you can get. You can't write method to apply a texture to a surface yourself because the GPU is built to be more efficient at doing this code than a CPU code can
I've switched from game making to engine making too. It just seems more directed and straightforward. I'm using metal n swift tho
What a coincidence, I just had my first ever OpenGL experience too! I only made a fragment shader tho, no fancy 3d.
very good! congratulations
"Eventually you're going to want to add more detail."
Yeah, I got as far as drawing a triangle, coloring the vertices, and making it spin. That was enough OpenGL for me lol :D
I guess everyone starting with OpenGL does that. I started with a triangle and then I made a cube and then I copied and pasted a random .gltf importer. After that I left the project. It has been 1 year. I will come to it soon. The hardest part in OpenGL for me is lighting. I can't predict what calculus is OpenGL doing on the background.
Talking to OpenGL is actually the easiest part of making a game engine. The hard part is building systems for meshes, textures, transforms, and scene trees around it in a way that is both robust and flexible at the same time. I'm at the point with my project where actual OpenGL code only makes up 10% of it, so I'm thinking about switching to Vulkan right away. It would actually make some things easier, since even the most recent OpenGL version is still somewhat stuck in the past conceptually.
All my OpenGL homies hate apple for deprecating it on all apple devices.
But jokes aside, OpenGL is great for starting with your graphics programming adventure. I was a part of a team writing a custom engine and a game. We tried to force Vulkan at the beginning of the project to make a "modern" engine, but after a month of stuggling with Vulkan we rewrote the entire month's progress in OpenGL in one day and finished the engine (and a game on it) in the next two months. It was a great experience.
To sum it up:
OpenGL and chill,
Vulkan and existential crisis.
dam youtube be telling on people with the most replayed bumb
Thanks for the DvA
im making a game engine / renderer using webGL/webGPU and SVGs for my A-level coursework. Its very rewarding when you get to more advanced techniques
I at first thought that you went with Vulkan which I would have applauded. I do recommend learning it or Webgpu since that api is a bit easier to learn than Vulkan but it is modern, cross platform and supports the web.
opengl should always be the first choice for a beginner, having such a large amount of control over the gpu is extremely stressful (even for experienced devs) and would be useless for a small project like this.
Fair but I also suggested webgpu as an alternative since In my opinion it is a good middle ground between control & simplicity. You can get a triangle on the screen fairly quickly without doing a lot of setup code but you'll also learn concepts and current best practices of how to interact with the api.
DirectX 11 is also a great middle ground that offers very good CPU performance as well.
@@nolram its def the best choice if you want to cater specifically to windows
@@billymays8864 Or Xbox (though they require DX12 now, but that's easy enough to port or layer) - and Linux with DXVK (DX11 -> Vulkan with DXVK is often faster than native OpenGL on Linux).
the most replayed part of this video is quite sus
lesson: don't.
the video is 4 minutes, i spent 10 minutes watching it. you guys probably know why
put it on 0.25 and do a gravity bong
welcome back:)
Does it worth learning? I would like to learn the graphic pipeline to be able to improve Godot but I dont have any knowledge yet
It is very time consuming but it's worth it (if you really want to know how rendering works).
Just don't touch Vulkan as your first renderer ;-)
No. At this point OpenGL is basically dead. Vulkan is they way to go, though it is a lot harder.
@@doufmech4323 True! But it's much harder and new developer could "get lost in the weeds" too easily ;-)
Haha I just spent the last few months doing basically this, I made a pretty simple 2d physics engine with just opengl and glad, and just last week I ported it to 3d and added obj loading. It's fun!
(and learnopengl is a godsend at the beginning)
I'm sure if you get to this project after a while you'll be 1000% better at it. Our brain needs time to understand things, sometimes, it's real time, like a month.