I tried coding my own graphics engine

try coding urself a functional brain at least a bit bigger than a nut

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 could kiss you right now.

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.

damn!! that's why it was the most replayed part

i skipped to highlight and what the fuck

I've switched from game making to engine making too. It just seems more directed and straightforward. I'm using metal n swift tho

In the early 2000s I was part of a small community for a PSX (and PC) game called "Warzone 2100". One of the projects I made was a 3D model editor capable of loading that game's 3D models, editing them (geometry/textures) and of course saving them directly back to that same (custom) file format. I started writing it in Visual Basic 4 but when later migrating it to Visual Basic 6 I researched how to link in the DirectX (7) library so that I could make the editor perform actual 3D rendering. Up to this point it was all just orthographic 2D wireframe polygons rendered through the standard Windows GDI; add some simple backface culling calculations (done by hand) and it was actually quite functional, but I wanted (needed?) the editor to be able to WYSIWYG with the model data.

HOO BOY was that quite an experience to learn. By the time I stopped working on the project, I had gone through all the phases of:
- Properly configuring the rendering viewport with the hardware (and needing to resize it on demand)
- Being able to render literally anything at all (vertex coordinates, camera geometry, window transformations, etc) even if it's just 1-2 triangles (plus I wanted to use perspectiveless rendering to match the orthographic GDI stuff I was already doing)
- Adding textures (which in this case meant being able to load texture files -- the game actually used .PCX format so, since DX7 didn't support it natively, I researched the file format myself to write my own PCX loader and WAIT WHY DID THE ENTIRE VB6 IDE JUST CRASH TO DESKTOP WHAT DID I DO WRONG? ...yeah, that ultimately was a bug on my part but solving it took literal months)
- Rendering an entire logical model (because it's really just a list of polygons, y'know? If you can get one to render properly you can easily render 10 or 50 or 100)
- Compositing multiple models together the way the game does (e.g. a "tank" may be composed of five distinct model files: the chassis, left tracks, right tracks, weapon/turret base, turret muzzle) -- which itself isn't too difficult because once you get one model rendering properly you can set up a loop to render 5 of them, right?
- Starting to implement animation transforms (the game had 2 animation modes: "animation frames" which was the 3D version of an animated gif, each frame being a separate model; and "animation parts" where each model was a separate bone in a larger animation rig, meaning I had to reproduce the game's transformation matrix and model heirarchy)

In the end, once you've built something on a lower level you REALLY start to appreciate how much inside work those more-polished toolkits and engines actually do for you.

Could you explain how developers deal with maps in terms of which part to render to not being rendering all the map each time, have you done that before? If so how do you deal with that?

Check out Pikuma graphics programming course for a more in-depth look under the hood. It's great.

Yeah I fell into this hole as well! Welcome to the fun, I have yet to progress. :'D

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

Not that difficult.

Devs of the game Haydee knew exactly what the players want

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.

Don't worry. I made a graphics engine that runs in the command prompt.

Your engine is infinitely better. Do not try mine, it was a "Can it be done?" project, and it does work but it's fuckin terrible.

Such a waste of time, learning a outdated framework to make something that already exists and is much better than anything you can ever make.. You don't even learn anything useful, cause the real advanced and complicated systems are something opengl already does, so you only learn opengl and there is no reason to learn that, learn something new and useful like vulkan maybe

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 :)

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.

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 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.

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.

"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've been trying to make a 3d game engine for 2 years, with over 100 failed attempts. And I can say that there will be some significant jumps in your code:

- Abstracting the OpenGL API:
A very light OOP wrapper seemed to work best for me, it helps to deal with OpenGL in a higher level, something other than modifying a huge state machine.

- Your first textured QUAD:
Not a triangle! Quads are obviously made of two triangles, this proves that your abstractions are coherent, the VAO setup is working, and the textures and samplers are being configured correctly.

- Getting models to load:
I'd recommend using a library at first for learning purposes, model loading is a royal pain, specially in a messy standard (Wavefront OBJ), or a more complicated one (glTF 2.0). Just make sure you're able to correctly extract the vertex info and render it.

- FPS camera:
Having the freedom to move around in your scene really ups the morale when making an engine, it also gives you the reassurance that nothing is breaking under different view points.

- Renderer
Which is just a fancy VBO, VAO and texture switcher, while also setting uniforms in your render loop. Try thinking about your "renderables" as a collection of properties they all share in common, such as transform, vertex format, material and others.

For each model, a VBO, for each transform, a *model matrix*, for every unique vertex format, a *VAO*, for every material, *textures, samplers and structs defining your material properties*.

Then, you loop through every object in the scene, extracting these properties and feeding them to OpenGL, and you have yourself a working renderer! Of course, it does much more than that, but it is a great starting point.



My last advices are to:

- Plan everything ahead:
Just make a .txt file with your current goals and how you're planning on achieving them. I've also started to write some sample code beforehand, just to get the gist on how I want my APIs to be designed.

- Don't give up:
Until now, I didn't mention how ~100 of those attempts were just the API wrapper, ~30 where I just got a triangle to show up, and only 3 times where I had a working camera.
Graphics development is a task of patience and perseverance, if you stick until the end, you'll get a MVP that everyone dreams of, but almost no one can put themselves through the struggle of making: a game engine that actually works.



And sorry for my horrible English, it isn't my first language, I hope it's understandable enough to be useful for someone who is making their engines from scratch.

I'm working on my own engine, using the knowledge I've got from all these attempts, documentation is dragging on as always, but I hope I can get it on GitHub rather quickly.

Please source code github link

"Most replayed"

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.

The game will never get finished…. Good luck, I’m unsubscribing

how does this video have more likes than views?

I remember when he made Godot tutorials. Many moons ago. The world has changed so much.

Why is the video hot-point the scene with the DVaRemake mod💀

streamm😭😭😭😭😭😭

Hey Garbaj, TarashHeep here.

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.

Nice to see Portal as example haha. Btw why not stick to OpenGL? I understand that it'll be the most compatible across board but you probably would be doing yourself a favour by working in Vulkan? Especially since it's easier to do ray tracing in Vulkan as opposed to OpenGL.

If you only ever want to do rasterization, then OpenGL is fine I guess

Have you considered Vulkan?

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

Huh I don't get it I'm creating my own game from scartch using open GL directly and for me it was simple as math

My game is about controlling multiple players to solve puzzels

Cool stuff.
I’m trying something similar.
Write a render pipeline (structurally identical to the gpu) but in software, to understand better what’s happening under the hood.
It’s quite fun, educating and frustrating. 😅
Learning and implementing the whole matrix projection/transform and homogenous vector stuff was quite entertaining. And to my surprise i implemented it correctly.
Only odd thing, I seem to using it wrong. As soon as I add perspective projection into it, the output looks crazy.
I also, gracefully, ignored the rasteriser and just use regular 2d painting apis (html canvas or skia) after the vertex shader.
Once the projection works, I will look into the rasteriser.

the most replayed part 💀

The Assless knight

most replayed part. not surprised.

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.

There is a guy doing this in notepad. how about learning some holy c troon

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!

Cool! Can you share your source code?

Lol nice job. I highly recommend binge-watching Ben Eater's series on building a graphics card using only breadboard connections.

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.