GeometryBatchFactory.mergeGeometries bug

Hello jmonkey forum users. I had a problem using the method mergeGeometries() on Doogee x30. Maybe one of the experienced users will help me. The essence of the problem is as follows:
I have a logic game, similar to flood it but in 3D, written in jmonkey. In the course of the game, I deal with many triangles of different colors (geometries), which to increase performance on mobile devices, I combine into several groups using this method. The problem is that the game works on almost all phones except Doogee x30 (and possibly other models). After a little debugging, I realized that the problem exists in mergeGeometries() method.
Here is the result of the printMesh() method before merging for a specific triangle:

Index:
[0, 1, 2]

Position:
[-1.8, 0.0, -1.8]
[0.0, 0.0, -1.8]
[-1.8, -1.8, -1.8]

Normal:
[0.0, 0.0, -1.0]
[0.0, 0.0, -1.0]
[0.0, 0.0, -1.0]

And here after using the mergeGeometries() method:

Index:
[0, 1, 2]
[3, 4, 5]
…
[30, 31, 32]
[33, 34, 35]

Position:
[0.0, 2.726002E23, 2.726002E23]
[2.725979E23, 2.726002E23, 2.726002E23]
[2.725979E23, 2.726002E23, 1.794E-43]
[2.725979E23, 0.0, 1.794E-43]
…
[0.0, 2.725979E23, 2.726002E23]
[2.725979E23, 2.725979E23, 2.726002E23]
[0.0, 0.0, 2.726002E23]

Normal:
[0.0, 4.6185E-41, 0.0]
[0.0, 4.6185E-41, 0.0]
[0.0, 4.6185E-41, 0.0]
[4.6006E-41, 0.0, 1.794E-43]
[4.6006E-41, 0.0, 1.794E-43]
[4.6006E-41, 0.0, 1.794E-43]
[4.6185E-41, 1.794E-43, 1.794E-43]
[4.6185E-41, 1.794E-43, 1.794E-43]
[4.6185E-41, 1.794E-43, 1.794E-43]
…
[0.0, 0.0, 4.6185E-41]
[0.0, 0.0, 4.6185E-41]
[0.0, 0.0, 4.6185E-41]

The method for some reason distorts the values ​​of coordinates and normals, and this happens only on Doogee x30, on my other phones and emulators everything works. This stuns me because the math method is too complicated for me. Can anyone help me with this? Unfortunately, I have no idea how to fix this, so I will be grateful for any help.

1 Like

Does the output look the same on devices where the code works fine?

The output mesh is obviously going to have different values because the transforms have been applied to the mesh data. If the values are bad then one place to look is the transforms. Perhaps on the “bad” device they get corrupted. Or perhaps that device does not have the floating point precision necessary to do the math.

pspeed, thanks for the reply. Yes, everything looks the same on work devices. I understand that this problem cannot be solved on this device?

I mean if the inputs and outputs are the same on all devices and doesn’t work on one of them… then it points to something completely different being the issue.

On all devices except Doogee x30, the inputs and outputs are the same and everything works fine. Most likely this, as you said, is a floating point problem of this particular device and it is impossible to fix it. By the way, the GeometryBatchFactory.optimize() function creates the same problems, so I think it’s a problem of the device itself and not the engine code.

I still say to check the transforms of the objects being batched. Just because this is where the problem is appearing, doesn’t mean it’s where it starts. If you can find the actual source of the problem then you may find a work around also.