JME3.1 - Rendering failure specifically for android 7 (Nougat)

[buenes]

play.google.com

Caps Racing

"In my time, during my childhood, kids didn’t get used to be stuck inside houses and condos. Video-games and computers were not available for all. All kids used to interact more and used their imagination to spend their time with fun games. They played with marbles, hide and seek, kites, go-carts, bicycles and other toys. One of these games that brings me joyful memories of my childhood is when we used to race with bottle caps (or "chapinhas" racing in Brazil). Houses were constantly in const...

Free

Hi guys,

I was testing my game with Android 7(Nougat) devices and discovered the occurrence of rendering errors for some objects in the scenario.

After much testing and research I came to the cause of the problem.

Every model obtained by the GeometryBatchFactory.optimize method renders rendering failure specifically with Androi 7 (Nougat).

Attached, screen 1 shows the situation without applying GeometryBatchFactory.optimize. Screen two shows what happens when you apply this method.

Screen 1:

screen_1_no_glitch.jpg

Screen 2:

screen_2_with_glitch.jpg

[rickard]

If it’s not too difficult, can you break up the optimized mesh into smaller batches? Ie, only do it for a couple of objects at a time. It could be a limit where the GPU on the devices don’t handle that many vertices or indices. (This goes against the theory that it’s a Nougat issue). It looks very OpenGL, so it feels like the Android version shouldn’t matter.

[Darkchaos]

But when it happens on the Emulator and only when specifying Android 7, it seems like Android.
However it is generally strange that they change things so that could break.

Actually I cant Imagine that they change GPU drivers or something, but yeah, maybe they changed something?

[rickard]

I have never trusted the emulator when it comes to OpenGL. Last time I checked it didn’t work at all.
Can you confirm that is the emulator and not a screenshot with frame?

[buenes]

Hi,

I created a simpler model and repeated the tests.

The results were the same. Both for emulator and physical device.

Follow the screens. I’m also making the program available to anyone who wants to test.

Screen 1

screen_1_no_glitch_2.jpg

Screen 2

screen_2_with_glitch_2.jpg

Program
https://drive.google.com/open?id=0B6PayivIlyTVc1h3NDZJcjRIMmM

[buenes]

Screen capture is from a physical device. But it was also tested with emulator

[rickard]

Tricky.

From wikipedia:

" Additionally, the platform switched to an OpenJDK-based Java environment"

“It was reported that the Google Compatibility Test Suite (whose tests must be passed in order to receive official certification) specified that all devices running Nougat must support either Vulkan or OpenGL ES 3.1 graphics APIs”

Unfortunately I haven’t worked with Nougat myself so I can’t help much. But it could be worth investigating if the switch to OpenJDK or OpenGL 3.1 could be the cause.

[buenes]

Hi guys,

I have identified the source of the rendering problem.

For this I created a more simplified model with two geometries of only three vertices each.

Then I printed the values of the vertices obtained from the merging of triangles in GeometryBatchFactory.optimize. The results follow below, and shows the values obtained in android 6 and android 7.

The values should be the same. But in android 7 we have strange values.

ANDROID 6

07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: Position Buffer
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 1.0, 0.0, 1.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 1.0, 0.0, -1.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: -1.0, 0.0, -1.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 0.8, 0.0, 1.2
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: -1.2, 0.0, -0.8
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: -1.2, 0.0, 1.2
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: TexCoord Buffer
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 1.0, 1.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 1.0, 0.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 0.0, 0.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 1.0, 1.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 0.0, 0.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 0.0, 1.0
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: Indexes Buffer
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 0, 1, 2
07-30 19:52:28.535 3899-3974/com.mycompany.mygame I/System.out: 3, 4, 5

ANDROID 7

07-30 19:48:39.832 9615-9644/com.mycompany.mygame I/System.out: Position Buffer
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 4.6006E-41, 0.0, 4.6006E-41
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 4.6006E-41, 0.0, 4.6185E-41
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 4.6185E-41, 0.0, 4.6185E-41
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: -4.28443616E8, 0.0, -6.35269E-23
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: -6.352771E-23, 0.0, -4.28447712E8
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: -6.352771E-23, 0.0, -6.35269E-23
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: TexCoord Buffer
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 4.6006E-41, 4.6006E-41
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 4.6006E-41, 0.0
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 0.0, 0.0
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 4.6006E-41, 4.6006E-41
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 0.0, 0.0
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 0.0, 4.6006E-41
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: Indexes Buffer
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 0, 1, 2
07-30 19:48:39.833 9615-9644/com.mycompany.mygame I/System.out: 3, 4, 5

Inquiring where these values were calculated I came to the source of the problem.

This is where you make use of the conversion of buffers to FloatBuffer.asReadOnlyBuffer.

The data indicates that it is a bug with the java.nio lib for android 7.

It makes sense because as already mentioned by rickard from the Android 7 the adopted Java implementation changed to OpendJDK.

In my case this bug caused the following problems:

1 - Rendering error for models obtained from the merging of two or more geometries in GeometryBatchFactory.optimize;

2 - Error of rendering of the material applied to these same models;

3 - Error in generating collision shapes in KinematicRagdollControl.

Sources Affected:

com.jme3.scene.VertexBuffer;
jme3tools.optimize.GeometryBatchFactory.

After eliminating the use of this type of conversion everything has normalized. I was able to do this simplification because my game has no thread safe question at this point.

[nehon]

This one is tough… Nice dig.
Do you really need to do the batching at runtime ?
Can’t you batch them with the sdk or whatever and save as a j3o file ?

[buenes]

Hello nehon,

That is a good question.

The explanation is how my production line is structured.

I create the model of the scenario with the geometries separated because there are two automatisms:

1 - The position in the starting grid is determined by the position geometries in the grid. After obtaining this information the program merge these geometries. Thus the program automatically discovers where to position the bottle caps in the different circuits;

2 - Running a race for the first time, there is an algorithm that takes circuit geometry and automatically mounts the track control. That is, this control identifies the limits of the lane and allows to obtain various information about the position of the caps throughout the race.
This limit control I save as a j3o because generating it is time consuming.
After that the circuit is merged with the terrain geometry.

GeometryBatchFactory.optimize done in this way has not impacted the load time of a circuit.

What’s more, today’s devices are getting faster and faster. I have seen the load occur in the blink of an eye for some devices.

[nehon]

Ok, makes sense. I’m a bit reluctant to patch the engine to work around a bug in another software… Idk how we should do.

[kaloyan.katsarov]

I`m using android studio and genymotion to test android. With android 6 all good, but with android 7.* I have this rendering failure. ( I removed the references of com.jme3.scene.VertexBuffer and jme3tools.optimize.GeometryBatchFactory from my project ) . I cant find any meaningful in logcat indicating the problem. Can you tell me what should I look for or test.

[buenes]

Hi kaloyan,

It’s hard to pinpoint a cause when we do not have the source.

But note that in my case the problem was in the use of the conversion function on the VertexBuffer, FloatBuffer.asReadOnlyBuffer.

This is a difficult problem to identify. What I did was create a minimal test scenario and gradually I was testing what worked and what did not.

As soon as possible I will make available the sources of classes com.jme3.scene.VertexBuffer and jme3tools.optimize.GeometryBatchFactory for you to see what I’ve changed. I have compiled these sources separately and replace the .class in the jmonkey packages.

[jayfella]

I’ve seen this issue three times now and every time it’s a Samsung device on nougat. Just throwing that in there.

[buenes]

Hi Kaloyan,

Follow the link to the files:

src.rar

Note that it is just a workaround.

[kaloyan.katsarov]

I did very simple test with rigged model.
private AmbientLight lightSelection = new AmbientLight(new ColorRGBA(1.75f, 1.2f, -0.95f, .1f));
private Geometry someGeometry;
public void simpleInitApp() {
tmp = (Node) ((Node) assetManager.loadModel(“Models/Enemies/devil.j3o”)).getChild(0);
tmp = (Node) tmp.getChild(0);
// tmp = (Node) tmp.getChild(0);
someGeometry = (Geometry) tmp.getChild(0);
someGeometry.addLight(lightSelection);
rootNode.attachChild(tmp);
}

(I usually convert the blend file through sdk option “Convert to j3o Binary” and load Node or Spatial I need recursively).
After I removed the bones (using blender and convert it) the geometry is rendered properly then I add again just single bone (no animation) “With automatic weights” (convert it again to j3o) and again render failure.
P.S. on android 8 there is no such problem

[buenes]

@buenes

Hi Kaloyan,

I have good news and bad news for you.

The good news is that you have been able to identify at what point the problem occurs.

The bad news is that you will have to investigate the JME source code.

What is the relationship between bones and rendering? Answer, animation.

The animation is made with bones, and it changes the arrangement of the vertices of the 3D mesh. That is, calculations with VertexBuffer.

My guess is that at some point the vertices are being recalculated due to the presence of the bone.

[kaloyan.katsarov]

Make sense. Probably I`ll make a try to dig in the sources.

[kaloyan.katsarov]

With getControl(SkeletonControl.class).setHardwareSkinningPreferred(false); helps for rendering issue but affects RigidBodyControl.class which is not workaround.

JME 3.1 cannot work fine in Android 7

Well; it’s not that good a news It means that there is a problem with hardware skinning in the shader. Can be a lot of things, but it can be related to the array of matrices we pass to the shader. Hardware skinning handles transforms of the mesh in the shader, software skinning handles it on the CPU (in the java code). Do you have an opengl error in the log by any chance?

[pspeed]

@kaloyan.katsarov

With getControl(SkeletonControl.class).setHardwareSkinningPreferred(false); helps for rendering issue but affects RigidBodyControl.class which is not workaround.

Animation and physics are totally separate things. So I suspect your method of detecting that it’s causing problems is in error.

Hardware skinning false should not affect bullet physics at all.