HDR on non-qualcomm devices?

Hi,

My game works fine on all the devices I’ve tested, as long as they have a Qualcomm CPU. If the devices do use another cpu, all the materials are black. The Galaxy S10 with the Qualcomm CPU works fine, but the Galaxy S10 version with Samsungs own Exynos CPU fails to render the materials. Same goes for the Huawei devices using Kirin CPU’s and any other non-Qualcomm CPU. But when I turn “Enable HDR” off, it works on every device, except now I’ve lost shadow casts and AA. Is it true that HDR only works on Qualcomm devices? If so, is there another way to achieve shadows and AA without it, and if not, what am i missing? How do i get it to work on all devices (API Level 14 and above)?

checked with the makers of those other devices yet? I don’t think HDR is exclusive to Qualcomm. What shadows and AA are used in the game?

I also don’t think HDR is Qualcomm (adreno gpu) exclusive, so i expect there is something wrong with my settings, but it is remarkable that those processing units can handle it while others can’t. I’ve tested it on 5 physical devices, and quite a bunch of devices using cloud testing.

Im using a dynamic light. Since there are only two objects in the scene receiving and casting shadows, and they are movable. The background is an unlit material. For the AA i’m using MXAA x8. I’ve read on some other threads that sometimes problems occur with wrong settings in the tonemapper, but I’ve not changed anything from default there.

That is really amazing. Qualcomm supposedly has the industry in chains, yet the whole of hardware is not predicated upon their technology. So, it’s similar to cars, where one maker tries to avoid certain issues and ends up creating other issues or defers to use a standard in preference of a creative or innovative endeavor. It’s tedious work checking all that stuff, but it’s necessary to produce the best quality often.

Did you check the log files yet?
Does use Full Precision for all materials?
Any materials using more than 16 texture samplers?

There’s some other guidelines in the docs for Mobile Platforms that need to be followed in order to avoid memory and rendering problems. Try checking those guidelines one by one, and seeing if one or more doesn’t align with the required restrictions and settings:

It may be something you’ve already considered, but sometimes a double-check is needed to confirm one didn’t escape notice.

Bloom is probably compatible with particular settings and setup. But it may be best to leave it off until the problem doesn’t return officially after those changes and testing. The thing about bloom is it has to be set in materials correctly, or it could break / not work / cause errors and artifacts. It sounds as though the background material being unlit could be a big part of the other materials not lighting up. The lighting in a scene bounces off of the background, whether it’s a skysphere, cubemap image, or something else, and can generate artifacts. I solved a problem with meshes having shadowy lines on their side surfaces in the 3rd person shooter template by disabling “Lower Hemisphere is Solid Color” in one of the lights (either Skylight or directional, don’t remember). I hadn’t added anything or changed anything in the scene when I first opened the template, and had other artifacts, then changes a few things to solve those and got the shadowy lines. It’s why I’ve tried to understand how these different lighting features work in conjunction so I don’t end up backtracking and testing the settings to no avail so often.

But the unlit material itself should lit up even without lightning in the scene right? And that was also not visible. Anyway I should take a look again at lightning in general and also the mobile example projects to get a better understanding of lightning. Much left to learn there.
But the initial problem did not reoccur, so I convert my previous comment to an answer. Thanks for your input Preston, much appreciated!

Thanks for the tips Preston! It seems fixed now, I’ve only tested it on 3 devices yet, but it works fine now 2 non-Qualcomm as well. I will run more tests soon.

I’m not yet sure what the real solution was because I changed a couple of things before testing. First I disabled Mobile HDR, let UE4 compile all shaders, enabled again and recompile everything. After that I turned bloom off in the project settings (read somewhere this could cause troubles on mobile devices), deleted everything except the r.MobileContentScaleFactor in the DefaultDeviceProfiles.ini. I enabled on all the materials the use of “Full Precision”. Finally I added to all my levels a post-proces volume (did not change any variable or setting from the defaults).

I’ve no clue which of the actions mentioned above solved the problem that was occurring. It may have been a combination of multiple actions. At the moment I do not have the time to try all these actions individually, but I probably will do it in the future. The last thing that rest me now is to (cloud test) my app on a lot more devices. If this problem does not occur again on another device, I will convert this comment to an answer.

Yeah, it’s a good tactic to make a list of the specifications and restrictions of lighting, especially for mobile since it has some really different ones. One user is having trouble with mobile separate translucency, even after setting things to what’s supposed to be correct, so overall it’s a matter of delineating the exact needs of what graphics are involved. Unlit needs at least one light, I think directional is it, whereas skylight isn’t needed (or the other way around) for it to display. Otherwise, it requires being plugged into the emissive pin of the main material node.

I’m going back to the docs a number of times to re-read things, and getting new understanding of even the more obvious points / concepts. It’s all a mix of different techniques, so one can enhance another, or one can interfere with another too. Settings need to be understood and remembered well, like remembering math equations and how they apply to different scenarios so the ability to problem solve is not of massive difficulty.