I believe jPCT has support for mipmapping but I've found it a little buggy for myself... (Or I'm just not sure how to make use of it properly)

It's actually a hardware thing. If it doesn't work, it's a driver thing o, on very old devices, an issue with the graphics chip. But other than that, it should work just fine....

Are you using your own shaders or the default ones?

I don't want the shadow or the part where the light isn't reached to be dark.

I'm not sure if I understand, what you want. Without shadows, there's no light. If you want something to be uniformly "lit", you can adjust the ambient light's intensity and/or color. You can also give an object an additional color: https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Object3D.html#setAdditionalColor-com.threed.jpct.RGBColor-

Maybe that helps? In general, all parts that aren't lit directly by a light source still have the ambient color and the additional color.

You can't, because that's the way in which lighting works as it takes the angle between a vertex normal and the vector from the light source to that point. In case of backfaces, this angle is larger 90° hance the darkness. Would it be otherwise, then there would be no lighting at all, because it would never get darker.

I see. jPCT-AE isn't thread safe in a way that it can render into multiple views from different threads at the same time. The reason for this dates back to the early days of Android where performance was largely hindered by the JIT-less Dalvik VM and it's awful garbage collection behaviour. You might want to try to add a static sync object to your class, like

private final static Object SYNC = new Object();

and then wrap your rendering code into a synchronized block like so:

synchronized(SYNC) {
            if (touchTurn != 0) {
                object3D.rotateY(touchTurn);
                touchTurn = 0;
            }

            if (touchTurnUp != 0) {
                object3D.rotateX(touchTurnUp);
                touchTurnUp = 0;
            }

            buffer.clear(back);
            world.renderScene(buffer);
            world.draw(buffer);
            buffer.display();
}

Yes, that's an awful hack and it might not even work properly, but there's no other chance to make jPCT-AE behave when you are doing the rendering in parallel. Another option is to use one view and either only display one model at a time or render them both into a texture and blit the result onto the screen to simulate the two different views. But that leaves you with managing touch events and such for both simulated views and such annoyances.

Oh, and one other thing: You can (and should) remove this line from the Renderer class:

_buffer.enableRenderer(IRenderer.RENDERER_OPENGL);

It's not needed here and will bite you once the window has the same dimensions as a valid fullscreen video mode by some coincidence.

Yes, I did. I played around with it, but I can't see anything wrong in the way in which jPCT handles this. I think that this is either an issue with LWJGL's AWTGLCanvas or Jide is doing some hacky things to work its magic that interfere with what LWJGL expects from AWT/Swing.

I managed to configure jPCT in a way that at least the box shows up, but the colors were all white after an undock. I think what happens here, is that the GL context that is bound to the AWTGLCanvas by some magic is lost when Jide undocks the canvas. When talking to an invalid context, it often happens that some things still work while others fail. This is more a driver bug than a feature, because actually, rendering into an invalid context should give you no rendering at all.

If that's the issue, I think that recreating the FrameBuffer actually is the correct solution here.

Another difference is, that you compile the non-batched objects as dynamic, but not the batched ones. Have you tried to use the exact same compile-call for the batched ones as for the non-batched ones?