How do you work with UE4 in spite of its slow compile time and lack of documentation of coding c++?
Hi. I’m a engine programmer who is developing a cross-platform game engine with c++.
I’m enjoying usually referring the UE4 code for developing the engine.
nowadays, I’ve want to know about this workflow in UE4:
Write a shader code (HLSL)
Create a Material Object with the shader code (in Editor or Code)
Write a code that make some object use my custom material with changing material properties
But It’s very hard for me to google the above workflow. There are only things about BP.
I know BP is quite useful, but I want to control most of the things in the code.
Even if I found some articles for the above workflow, they are normally outdated because nowadays UE4 changes its mesh rendering process.
So, Normally It’s hard to find a article of doing a basic coding in UE4 C++.
In addition to the lack of documentation, the compile time is insanely slow.
When I create one actor header and cpp, and try to compile it for seeing what’s going on,
It normally takes more than 1 minutes to compile just one added header and cpp.
I already googled about the compile time optimization like fastbuild, increbuild, NVIDIA Geforce Expereince, something like that.
But it’s too complex to configure it.
So, What I said is quite an offensive complaint.
In the meanwhile, I also want to know about your journey to overcome these kind of problems.
And I also want to know about Why do you keep using UE4 despite of those problems mentioned above.
You don’t really make materials or shaders in code, that’s what the material editor is for and what the engine expects you to use. Should be pretty rare that you need to type a single line of HLSL unless you’re doing something very specific. You can use Dynamic Material Instances to change properties at runtime.
To be honest, the source code is the documentation.
Both FASTBuild and Incredibuild are useless unless you have a build farm or a few spare machines on your LAN. UBT already distributes work accross all available cores. FASTBuild is free but frankly I’ve never managed to find an implementation of it with UE4 that works for more than five minutes - and Incredibuild costs absurd amounts of money that would be better spent on a Threadripper.
Adding headers takes a while for sure, especially as UHT has to go through and parse/create all the generated code - but Live Coding significantly improves CPP iteration time.
I will not agree. This may be true for small projects, but not for beasts like the UE4. Generally approach like this is harmful.
Source code and documentation are two different things.
Source code shows how the something works internally, give you all implementation details.
Documentation shows what a given thing is and how to use it.
Docs strip off all useless from user perspective things like private methods, helper structs, etc.
I think what Jamsh is saying is there are lots of examples of those systems being used in sample apps and throughout the engine. ShooterGame will show you have to build everything from a custom ReplicationGraph to how to do “syncd” RNG between client/server. Also menu flow and everything.
Documentation will never be able to keep up with all the changes to UE4. There’s some good core documents (the Actor Lifecycle for example), but anything that gets at a feature level tends to go out of date pretty quickly.
Yeah precisely. For some reason the example projects seem to go ignored, but they are far more useful than static documentation because you can see an up-to-date working example.
Epic regularly update these samples to showcase new engine features too (ShooterGame has a fully working Replication Graph, for example). To respond to the original post though, I personally never really use the documentation at all. If I need something I’ll look at one of the sample projects.
I have 3 seconds for an incremental compile but the Header Tools call adds another 7 seconds to an (incremental) build of a Developer Editor edition. Is there something I miss in this regard? Hot Reloading in an Editor instance adds another 3 seconds.
Saying that I do not think that changing C++ code is slow. I would love to have C# or Java compile speed but I can live with 10 to 13sec as I do not do TDD in Unreal.
So turnaround time for me is 13s on a first gen Threadripper with 128GB ram.
Are you using source control? I find the more files that are source checked out (and thus writable), the more UHT tries to double check things and can’t add them to the unity compilation. Once I check those in, UHT takes no time at all. Also UHT will be bound more by disk speed than CPU.
@ExtraLifeMatt I have a local git server I synchronize against at home. I backup this server using drop box. I use source tree to commit and push changes locally. My UHT always takes at least 7 seconds after the first initial compile which takes about 29s. If everything is checked in, I still have 7s for UHT and about 13s overall. My disk speed should be very good, too, since I custom build my system using a fast SSD. If there is anything I do wrong or can do to speed things up, I would be glad to be informed about it… .
I’m using visual studio 2019 not sure which build (im at work) but I saw a huge difference between unreal 4.23 vs 4.24. If I do an incremental build on a c file, we are talking 1-2 seconds compile time and then just hotload time after that, which is about 1 second extra for me.
of course if I touch a header file, then the compile times are longer. Not sure if project size will matter or not by my project isn’t too big right now.
Well there is a bug that always will include UHT in any build. I got it solved by touching the target file as mentioned in the link. Bad thing thou, I always code against header files only unless I have static members to define. So I run UHT still quite often but only if the signatures of the class/fields/methods change so I am still happy especially when you fix all those complaints the compiler has when I was on a coding spree.
My project currently is half a meg of C++ code plus the usual something more. So 3 to 5s for compiling and hot reloading is quite nice when compared to around 12s.
I’m not sure you are right about Incredibuild. I’ve been using it for free (not valid license), you don’t have all features, but still speeds up compiling time. I’ve tested it and even with an invalid license, it’s faster. Worth a shot to try out.
UBT already distributes work to all available cores on your machine, so aside from distributed shader compiling it really can’t do anything the engine won’t already do for you. Last time I used it, it was considerably slower because of the time it takes for IB to spool up.
All that aside though, you’re better off spending that cash on a monster CPU like a Threadripper - it’ll be far cheaper in the long run, and on the latest TR’s you can do a full engine compile in <10 minutes on one machine.
A quick tip about compile times. Write out as many function definitions and decorations as possible at once. Adding a function increases compile times. Changing logic in function does not.