Hi @, it’s a sort of banner system for a TV show - A team consists of a logo and three team portraits which are selected and loaded at given points. So UE receives paths to image files, loads them in, composites them in UMG and writes them to a texture which appears on geometry. Even if I put a delay in between loads it still hitches. I’m just looking at a threading plugin which may well work, but crashes the editor a lot (because i don’t know what i’m doing, I expect.)
The ‘bytes to texture’ functionality cannot be multi-thread for as far as I know, it is synchronized to the engine thread on purpose, since the code that runs on that thread isn’t thread-safe (for performance reasons).
Do these hitches only happen once, or do they lag the entire game/application down?
Are the images too large for their use perhaps (like 1000x1000 pixel images for 100x100 pixels on the screen)?
Perhaps you could experiment with different image formats (png, jpg, etc) to see if there is any difference in performance there.
They’re necessarily either 512x1024 or 512x512, and they have transparency so png is my only option (I think). I’ve just been running it inside BPThreads with some success (makes me worry though that you say it’s not thread safe). I’ll be giving it a battering to be sure. And yes, it always hitches by about 2-3 frames on each load, which will have to happen fairly often, and there are 70+ of these images, so I can’t really pre-cache them. All though I suppose I could serialise them and save them - but I have no idea how this would work performance-wise.
I see, weird. Using BPThreads should be fine, the code in the ‘bytes to texture’ blueprint is synchronized, so that won’t error or crash as far as I know.
Not sure why it takes 2-3 seconds, or is that for 70+ images all at once?
PNG has several different ways it can be encoded, as in interlaced, compressed, etc. You could experiment with this (the compressed option especially) and see if the lag/hitching will be gone then.
I don’t think you can cache textures, you are able to cache the bytes of the images, but that would just save you on the downloading part (which is async), so that won’t fix the hitching.
Hi, I am getting the error below from LowEntryEncryption when packaging to Android. Engine version is 4.20.3. This wasn’t happening when the project was at 4.20.0. Please help:
Oh I see, thanks for letting me know! I already know how to fix it. Publishing it to the marketplace will take some time though, seems like Epic is taking a vacation, so that might take 1-2 weeks hopefully.
I’d like to solicit any pointers that anyone might contribute in so far as the proper procedure for using the LowEntryStandardLibrary in C++. I’ve tried just adding the header file to my .cpp file but get an error about VS not being able to find one of the generated header files.
I haven’t tried including the LowEntryStandardLibrary myself, but in the header file, these classes are defined which are then imported in the cpp file:
class ULowEntryLatentActionBoolean;
class ULowEntryLatentActionFloat;
class ULowEntryLatentActionInteger;
class ULowEntryLatentActionNone;
class ULowEntryLatentActionObject;
class ULowEntryLatentActionString;
class ULowEntryParsedHashcash;
class ULowEntryByteArray;
class ULowEntryByteDataEntry;
class ULowEntryByteDataReader;
class ULowEntryByteDataWriter;
class ULowEntryBitDataEntry;
class ULowEntryBitDataReader;
class ULowEntryBitDataWriter;
class ULowEntryLong;
class ULowEntryDouble;
class ULowEntryExecutionQueue;
I don’t think including these is needed unless you use a function that requires one of these classes to be defined.
You might want to include them all and see if that solves the problem.
By the way, in some cpp files I’ve included the LowEntryStandardLibrary as well, like for example in LowEntryByteDataWriter.cpp, so you could take that as an example and see if that might work, I’m not sure if including from inside vs outside the project (the plugin) makes any difference.
(post does not like the left and right angle brackets around the type, so these are omitted here but not in VS)
generates an error:
Error C2139 'ULowEntryByteDataEntry': an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_trivially_destructible' Colony2 e:\epic games\ue_4.21\engine\source\runtime\core\public\Templates\IsTriviallyDestructible.h 18
No it’s currently not possible, it would require a thread and that can cause a whole number of problems, plus it might also require reading a file line-by-line so it won’t flood the memory. For anything really performance cloggingly heavy I would do it in C++, that way you’re free to make it work in a way that’s acceptable performance-to-functionality wise for your specific use case.
Thanks for the info! I also noticed the problem wasn’t the file size, but the huge amount of operations (seperating csv data), so I’ll be able to come up with my own solution. Cheers!
Hi, the LE HTTP Request plug-in doesn’t work on apps packaged for Android 64-bit arm64, only Android 32-bit armv7 (it seems to work fine for 64-bit versions on iOS, MacOS and Windows though).
The error message I get is the following:
“Plugin ‘LowEntryHttpRequest’ failed to load because module ‘LowEntryHttpRequest’ could not be found. Please ensure the plugin is properly installed, otherwise consider disabling the plugin for the project”
This only happens for 64-bit arm64 packaged android apps, not 32-bit armv7. This wouldn’t be a problem, just use the 32-bit version, but Google will soon require that we upload a 64-bit version of apps to the PlayStore, in addition to 32-bit. So I’d be uploading something that the end-user can’t use.
