Issue in older graphics cards AMD 7000 series


I have a code where I implement the diamond square algorithm.
If anyone knows how to address the further described problem please give me a hint/solution.

The code generates and renders the terrain without any problems in newer graphics cards that are in the supported graphics cards specs for developers:

In older cards namely AMD 7000 series.

There is a weird behaviour which is the meshes when rendered overlap and instead of multiple squares I have 1 and also the square(a) fleea with the camera, they literally move. Sometimes I can get a glimpse of them fleeing.
In a more recent supported graphics card
The code responsible for creating the meshes from the heightfield/heightmap is:

     ArrayList<ArrayList<Vector3f>> Heightfield; 

     * This method returns the terrain generated with the diamond square
     * algorithm.
     * @return the last terrain generated with the diamond square algorithm.
    public ArrayList<Mesh> getTerrain() {
        ArrayList<Mesh> meshesTerrain = new ArrayList<>();
        for (int i = 0; i < (Heightfield.size() - 1); i++) {
            for (int j = 0; j < (Heightfield.get(i).size() - 1); j++) {
                Mesh meshTerrain = new Mesh();

                Vector3f[] verticesTerrain = new Vector3f[5];
                int[] indexes = new int[2 * verticesTerrain.length]; //Indexes are in pairs, from a vertex and to a vertex
                for (int k = 0; k < verticesTerrain.length - 1; k++) {
                    indexes[2 * k] = k;
                    indexes[2 * k + 1] = (k + 1);

                verticesTerrain[0] = new Vector3f(

                verticesTerrain[1] = new Vector3f(
                        Heightfield.get(i).get(j + 1).x,
                        Heightfield.get(i).get(j + 1).y,
                        Heightfield.get(i).get(j + 1).z);

                verticesTerrain[2] = new Vector3f(
                        Heightfield.get(i + 1).get(j + 1).x,
                        Heightfield.get(i + 1).get(j + 1).y,
                        Heightfield.get(i + 1).get(j + 1).z);

                verticesTerrain[3] = new Vector3f(
                        Heightfield.get(i + 1).get(j).x,
                        Heightfield.get(i + 1).get(j).y,
                        Heightfield.get(i + 1).get(j).z);

                verticesTerrain[4] = new Vector3f(

                /* Setting the Meshes Buffer */
                meshTerrain.setBuffer(VertexBuffer.Type.Position, 3, BufferUtils.createFloatBuffer(verticesTerrain));
                meshTerrain.setBuffer(VertexBuffer.Type.Index, 2, BufferUtils.createIntBuffer(indexes));

        return meshesTerrain;

To render I do:

        ArrayList<Mesh> meshesTerrain = t.getTerrain();

        /* Using the Mesh in a Scene */
         * We create a com.jme3.scene.Geometry and com.jme3.material.Material
         * from our mesh, apply a simple color material to it or perform vertex
         * coloring, and attach it to the rootNode to make it appear in the
         * scene.
        //Using the mesh together with the Unshaded.j3md material.
        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        //activate wireframe
        // set the same color for all vertexes
        //mat.setBoolean("VertexColor", true);
        mat.setColor("Color", ColorRGBA.Red);
        for (Mesh m : meshesTerrain) {
            Geometry geoTerrain = new Geometry("Terrain", m); // using our custom mesh object  
            geoTerrain.setLocalTranslation(-size / 2, -size / 10, -size / 2);

        /* Debugging Tip: Culling */
         * By default, jME3 optimizes a mesh by “back face culling”, this means
         * not drawing the inside. It determines the side of a triangle by the
         * order of the vertices: The front face is the face where the vertices
         * are specified counter-clockwise. This means for you that, by default,
         * your custom mesh is invisible when seen from “behind” or from the
         * inside. This may not be a problem, typically this is even intended,
         * because it's faster. The player will not look at the inside of most
         * things anyway. For example, if your custom mesh is a closed
         * polyhedron, or a flat wallpaper-like object, then rendering the back
         * faces (the inside of the pillar, the back of the painting, etc) would
         * indeed be a waste of resources. In case however that your use case
         * requires the back faces be visible, you have two options: If you have
         * a very simple scene, you can simply deactivate back face culling for
         * this one mesh's material.

        // END OF EXERCISE 2 (Step 2). -----------------------------------------  

         * add ambient light. Since, ambient light does not in reality exist we
         * shall call it god because like ambient light god is everywhere ...
         * assuming god exists obviously. If it/he/she does or doesn't exist is
         * in the scope of theology not science.
        AmbientLight god = new AmbientLight(); //because god is light and god is everywere 
        //got..setDirection(new Vector3f(-10.0f, -20.0f, -10.0f));    // The direction where the light is pointing (-1, -1, -1) and the light position (10, 20, 10)

The expected result in newer cards I get is:

To anyone that reads this post (regardless if you give input or not) best regards.

Found a solution today.
//mat.setBoolean(“VertexColor”, true);
should be commented and replaced by
mat.setColor(“Color”, ColorRGBA.Red);

I posted the code without the problem and for chance was tenting it today and it was working and I did not know why.