Yep, that's the exact same issue that I had with these PowerVR chips as well, regardless of using AA. That's why jPCT-AE now defaults to not use VBOs on these chips if detected. That was the only solution that I found that fixed it. Maybe you are enabling VBOs somehow again? Or maybe you are using an older version that doesn't include this fix...are you seeing some PowerVR related setting in Config?

Grabbing the screen rendered by the AWTGLRenderer is a bit of a pain anyway, because the calling thread (the one that want to grab the image) has to trigger a repaint and then wait for the paint thread to do that. I'm not sure how this should result in an endless list of calls though. Check what happens in the AWTGLRenderer's waitForPainting() method. Maybe canvas.isVisible() returns always false in your implementation or something like that.

So maybe it's just something that you are calling recursively by accident? Something like

callMe() {
    // callMe(null); // What you are supposed to call
    callMe(); // What you actually call by accident

}

callMe(SomeStuff stf) {
    ......
}


I tend to do these things when refactoring code, hence the idea.

So the C#-Runtime doesn't feel obliged to print the actual location of the exception? That's strange.

In that case...I don't know. Maybe using a debugger helps to find it or, which would be what I would do, adding some log output to each and every method that might cause this...

That looks strange. Have you tried to render a simpler model like a sphere from the Primitives class and increase it's polgon count?

There is no actual limit on what you can load and display as long as loading times are feasible and it fits into memory. So there's no "cut off after 4 MB"-setting or anything like it.

In your case, it might be a problem with the model itself, with the 3ds loader, with the way in which you serialize/deserialize the object or, maybe most likely, this setting: https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#maxPolysVisible

You might want to adjust this first to see if that does any good. When you load the object, there should be some log output that tells you, how many sub-objects the object compiler has created . If that number exceeds this setting, you'll lose parts of the model when rendering it as a whole. If you can't find this information, just double the value to see if that changes something.

If that doesn't help, a screenshot of the issue might give an indication of what might be wrong.

These are the transformed normal vectors' coordinates. It might be possible, that the x coordinate is 0 for some polygons in your object (albeit unlikely). But that wouldn't affect the polygons where it isn't. I would assume that there's still something wrong with your check for "has been processed already"...that this wierd magic number, like here:

if (arrays[0][pos3] == 12345671 || isFlatShaded) {

Just change these occurences into something like

if (arrays[0][pos3] == 12345671 || isFlatShaded || true) {

If that helps, your handling/setting of this magic number is wrong.

That's a placeholder value that indicates "not yet filled". Do ask why it has the value it has...I can't remember. Anyway, there should be code like this somewhere to clear this cache:

transformFlags[i] = 12345671;

Maybe you've ported that "away"...?