Black areas/flickering in my Android app (solved)

I am in the process of testing my 3D app on various devices and with bundles of various compression levels.
Everything runs fine and smoothly on Windows, Linux. In the Android Studio Emulator, I tested with several devices and several API levels, everything is fine.
The app runs without stuttering as well on my old Samsung Galaxy Tab S 700, but I get black flickering and black areas like this one:


Logcat reports no warnings or errors.
Has anyone here experienced a similar issue?
Sorry, forgot to add:
both the frames and the skirting boards in the image are a few centimetres away from the walls.

Do you get any info in the logcat (the Android logs)?

1 Like

Hello @Mathias_Westerdahl, thank you for your reply.
No, logcat seems fine:
Errors:

2022-04-26 08:47:25.569 9899-9899/? E/Zygote: v2
2022-04-26 08:47:25.574 9899-9899/? W/SELinux: Function: selinux_compare_spd_ram, index[1], priority [2], priority version is VE=SEPF_SECMOBILE_6.0.1_0035
2022-04-26 08:47:25.574 9899-9899/? W/SELinux: SELinux: seapp_context_lookup: seinfo=default, level=s0:c512,c768, pkgname=com.example.todo 
2022-04-26 08:47:25.784 9899-9899/com.example.todo W/ActivityThread: Application com.example.todo can be debugged on port 8100...
2022-04-26 08:47:25.854 9899-9899/com.example.todo W/ResourceType: Failure getting entry for 0x01080a97 (t=7 e=2711) (error -75)
2022-04-26 08:47:26.059 9899-9917/com.example.todo E/defold: ERROR:DLIB: ../src/dlib/socket.cpp( 289 ): SOCKET: Unknown result code 92
2022-04-26 08:47:26.064 9899-9917/com.example.todo E/defold: ERROR:DLIB: ../src/dlib/socket.cpp( 289 ): SOCKET: Unknown result code 92
2022-04-26 08:47:26.064 9899-9917/com.example.todo E/defold: ERROR:DLIB: ../src/dlib/socket.cpp( 289 ): SOCKET: Unknown result code 92
2022-04-26 08:47:26.064 9899-9917/com.example.todo E/defold: ERROR:DLIB: ../src/dlib/socket.cpp( 289 ): SOCKET: Unknown result code 92
2022-04-26 08:47:26.064 9899-9917/com.example.todo E/defold: ERROR:DLIB: Unable to create socket for ssdp
2022-04-26 08:47:26.064 9899-9917/com.example.todo W/defold: WARNING:ENGINE: Unable to create ssdp service (-1)
2022-04-26 08:47:27.889 9899-9917/com.example.todo E/defold.sound: App is missing the READ_PHONE_STATE permission. Audio will continue while phone call is active.

Info adds transcoding info like this one here:

2022-04-26 08:47:46.339 9899-9917/com.example.todo I/defold: INFO:GRAPHICS: Transcoding: /assets/uvs/bildportrait.texturec from 12 to 0 (TEXTURE_FORMAT_RGB_ETC1 -> cTFETC1_RGB)

Apart from the above, Verbose/Debug report input events:

2022-04-26 08:52:41.999 9899-9915/com.example.todo V/threaded_app: New input event: type=2

Hmm, it’s already TEXTURE_FORMAT_RGB_ETC1 when it’s compressed?
What do you compress the texture to in your texture profile?

I suggest using BASIS_UASTC as the texture compression.

I get the flickering with all sorts of compression levels. Give me a sec, I’ll install the basis_uastc bundle and get the logs.

Right, I am back. Took a bit, I had deleted the bundles I made yesterday :roll_eyes:
I installed a basis_uastc bundle and then tried a default one.
Logcat does not complain. Error is the same as above, the transcoding bits are gone and input events are reported.
I think, the transcoding came from the fact that I forgot to remove the build folder after bundling with etc1 when I bundled right away again with basis_uastc.
Anyway:
these are the settings I used:
Screenshot 2022-04-26 at 09.28.25
Screenshot 2022-04-26 at 09.30.20
for the test with basis:
Screenshot 2022-04-26 at 09.18.49

And it works if you don’t use texture compression?

What size is the atlas in question?

Sadly, same situation with a default bundle.
There is only one atlas with a tiny image (320x320 px) used as a background for a gui box node.
The rest of the images are uvs that are added as a texture to my models:
Screenshot 2022-04-26 at 10.27.15

Screenshot 2022-04-26 at 10.28.19

Ok, so the model uses a .png directly.
What format is that .png? Indexed? RGB?
What size is it?

I consulted the GIMP:
Screenshot 2022-04-26 at 10.48.41
The images are all of the same size, 1024x1024, rgb, 8 bit, png.

Ah, so it could use an atlas as well?

No.
But for some reason I thought we were talking about atlases :slight_smile:

1 Like

Looks like z fighting to me. Can you replicate this in a sample project?

1 Like

I’m not sure I understand the info for that image.
Size in memory should be 102410243 = 3mb ? (or 4 if rgba)

What if you run this:

$ file ./assets/uvs/bildaoeforst.png

:grinning_face_with_smiling_eyes:

To me, too. Curiously, it only is a problem on my android device.
I run into a bit of a conundrum: Paintings tend to hang on walls, I can’t move them too far away without the whole thing looking odd. And I can’t leave noticable gaps between walls and stairs, doors and skirting board etc. either.

See, I don’t understand anything about them :grinning: Will try the command.

This is what comes back:
bildaoeforst.png: PNG image data, 1024 x 1024, 8-bit/color RGB, non-interlaced

1 Like

Just dug out a much smaller prototype I had made: same thing.

One thing that helped my project is to change the camera “range”; I use Rendercam and set the “near z” to the biggest value I can get away with and “far z” to the smallest. This didn’t completely fix the issues I was having, but ended up being completely acceptable.

1 Like

That looks like a proper rgb texture then.

Then I don’t know what to look for.
I suggest you create a minimal repro project that you can share with us in order to test it out.

1 Like

Thank you @totebo, I will try this out immediately.

I’ll do that and it is very kind of you to offer to have a look.
Will be back soonish.

@totebo, may I ask you what near z and far z I might want to try for a large model of 100x100m?

It depends entirely on your game; how far the camera is from the object and what cutoff points are acceptable.

My game is fairly extreme in that you see quite far in the distance. I’ve set the near to 300 and far to 100000 I think.

1 Like