Hey, anyone knows about any good blogs that dive deep into UE4 code?
I started looking into the engine code a few weeks ago and I can really use a good reading material on it.
The documentation portion of the website does a pretty good job documenting the gameplay framework but the rest of the engine is largely undocumented. If you have a problem with a specific portion of it, you can post on the AnswerHUB and maybe get an answer from one of the developers responsible for that section of the engine.
The engine code is massive and written by literally hundreds of people over the last 5+ years. There is also code inherited from past versions of the engine which could be much older. The engine is also updated daily, sometimes in very big ways. To have documentation on all of it simply is a task that will never happen.
I recommend focusing on areas you wish to use. Read the code and use debugging to try and get a grasp on what it is doing. It is no small task and I seriously doubt there is anybody that truly understands the entire code base so finding anything like “here is how all of UE4 works” won’t happen.
I do not agree with the stated above… i mean, i know the engine is massive, but one should create the documentation alongside the programming.
While i haven’t created a program this massive i have created some programs for Telefonica, Oxford, etc with National scope (on my old jobs)… and saying “is too massive” or “is updating daily” was not an excuse for lack of documentation, especially if the team is massive… more the reason to be well documented.
I feel that the engine can do a lot more to be better documented, but again, i do not know the process that goes inside unreal engine, i only know of what is considered a “normal” project scope, and documentation is part of what should be considered by every programmer.
I myself haven’t had much trouble delving deep into the engine, but sometimes there’s a lot of “missprogramming” or variables that get created and never used… things that some code review would solve easily
Edit: added some points
2 Likes
Open sourcing the engine doesn’t mean Epic is putting all its knowledge to the table. It shows in the quality of public documentation! I guess if you want to dive deep into UE4 source first have a basic understanding of how a game engine in general works, how its parts are split up and what concepts are used to structure the engine. Than its an easier read.
I started with a similar mindset to try to understand everything, but let it go! Its either game engine 101 you have to tackle or ue4 specifics that are answered somewhere in forums or AnswerHub.
Great summary of all important concepts: Unreal Engine for Programmers (GDC 2014 talk)
Understanding some of the source code
Ok, I’ll try to be a bit more specific.
I am mostly interested in the rendering part of the engine as I’m currently trying to build my own simple game engine for practice.
The areas I’m most interested in at the moment are the way the material system works and how the expression nodes turn into shaders and how these shaders are binded and uses in the pipeline.
I’m also interested about the way all the different rendering passes work and how they interact, also the way the scene graph provides the renderer the list of primitive components that the render will be using for each of its passes.
Regarding the shaders pipeline, I figured out the way that expressions are compiled into HLSL code and then compiled again into intermediate shader language, so basically I got this area covered by now.
What I’m still failing to understand is the way shaders are getting binded to each pass and how each pass gets the list of primitives its supposed to render.
I tried going over FDeferredShadingSceneRenderer::Render as the documentation suggested but its a really complicated area to look at it and after a couple of hours on it I’m still failing to get the overall picture.
I’m about to finish reading “Game Engine Architecture” so that covers the engine 101, I’m using UE4 as a practical example to how a commercial game engine works.
Anyway, any pointers regarding the way the graphics pipeline works in the areas I mentioned would be a huge help.
To me will be enough if source code becomes well-commented.