Unreal and the issues that come with development on it

Unreal can be really annoying....

Unreal currently can be one of three things: Useable, A slight pain or a program that will not run no matter what you try and do.

After working with unreal for many years now and within developmet and the recent encounters of drive failures, I have learnt some interesting outcomes from development with how it processes data,  computes lighting / shaders and how to make it work faster and other processes on how situations with crashes and when they were encountered.

Atlhough the blog is about the issues seen, you'll find as the further down the blog you go, it becomes a chain like object

Random crashing

On occasion, the engine will close at random which has happened depending on one of the following situations rising:

Changing a instance mesh texture from an texture file to a standard material.
Placing an object into the world
Converting the object to another object
and the most favourite one, compiling changes to the nodes of the AI movement.

These are the more common issues I have found that seem to create crashes which then close down my project with at times wasting hours of work for the slow goal of completion.  Although this is not a massively negative thing, it can make working incredibly fustrating but one way to go around this is the build process.

Building engines

Build engines does what it says on the tin which although sounds weird as it's standard, the issue with it is that I learnt that building the level regularly will stop a lot of the issues with crashing happening.  Although it sounds like i do it on a daily basis, I keep the norm now of doing a build once every week if possible.  The research I did backs this up as other people seem to have the same issue with the engines being built stopping a lot of issues, specially around the problem of changing materials or object placement.  It seems that its more orientated around the streaming of textures as well as the optimisation of data processing.  This however for fixing it can cause delays with processing the data and slow down of the machine whilst working.

Shader compiling

Another thing that is seen from the crashing is that the shaders need to be compiled again (usually around 250) which can draw massive slow down of the PC as it uses a lot of processing power to calculate the data.  This again slows down the process even more but it's strange that it needs to constantly have to process the information.  Researching into why unreal does this, there was a interesting fact i picked up on the forums that helps effectively cut the time down.

Focusing on other programs does to unreal

CALC.EXE!  The legendary calculator has another suprising effect other than mathematically calculating numbers into a bigger number.  If you put the main focus of the PC onto the calc, the processing of shaders takes considerably less time to compute the information that if you had focus on unreal itself.

Watching the processing done via focus on unreal is 15 shaders per 2 minutes.

Whilst focusing on the CALC.EXE, it processed 180 within a minute.

Although there is no information from epic on what this happens, other devs and researchers believe that the issue correlates to how it processes data or runs when not focused.  Its a possibility that unreal acts like a seperate program when working in the background that in the foreground.

I have no idea why but it is a massive time saver and an amazing find which has made it work quicker and processing data.

Computating data complete (BP vs C++/BP vs C++)

With the noticeable improvement that is the processing of shaders, made me go into more research into issues that can be seen with the processing of blueprints or classes and how they can effectively run or importantly slow down the processing of commands of data.

After researching into various processes of trying to keep my FPS up in game due to optimisation.  One thing that was noticed on the forums was about the delay in blueprints completely or delaying overall to the use of C++ coding.

With that, I did more research and found that although blueprinting is more efficient and helpful to budding new start up teams or people who do not want to code, the push for delay is greatly increased against those who use C++ to blueprint. 

With processing a for loop calculation taking around 2 ms to process on C++ to 400 ms on bps.

It's suprising what this can do to slow down your machine which is incredibly hard to fight against but at the same time, it doesn't suprise me that it's happening.