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
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 :)
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.
@@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.
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.
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.
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.
@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.
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.
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
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 RU-vid 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 😌
RU-vid 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
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.
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!
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).
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 ;-)
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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'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 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
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'm a rendering programmer by trade and I can say quite confidently that it doesn't ever stop with feeling overwhelming or like there always being a more complex thing to learn 😅 Rendering is such an in depth discipline and requires such depths of knowledge anywhere from physics to photography or painting to statistics; so no one person can ever truly know it it all imo and it's always best to take comfort in that 😉 I would suggest, given you're starting out, just pursue what you're finding fun! If you start looking into a topic and are feeling overwhelmed please don't be too discouraged! It's perfectly fine to put that topic down to come back to later and try something else for a bit 🙂 E.g. You mentioned that you struggled with the model importer and lighting. So why not place them down for a moment. For models, why don't you try making basic levels out of cubes and then move towards having those levels/models read in from your own simple file format? It would give you an appreciation for what sort of information is included and how it flows through the graphics pipeline whilst still being grounded in something you know. For lighting start simple! Don't worry about shadows for now, just worry about the 3 building blocks: diffuse (The base brightness of a surface), specular (The "shiny" spots on surfaces) and ambient (The background colour you get from light that, irl bounces from object to object) There are many resources on basic lighting thankfully! Once you're feeling comfortable with those, it then opens up the opportunity to dip your toes into most other lighting topics/sub disciplines 🙂 Hopefully this was helpful!
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!
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)
Thats cool! I coded a realtime and raytracing engine myself with raw 2D shapes but never learnt OpenGL. So thanks for the quick overview since I may wanna touch it at some point because the performance in my (single-threaded purely cpu based) realtime 3D engine is... not the best😅
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.
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.
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.
