https://numbermonk.com/hexadecimal/65535

I'm guessing then it's either context change, resuming of renderer or pausing of renderer...
I don't think it could be anything else..?

I believe I did have some issues with NullPointerExceptions before when resuming/pausing/changing context. I did catch it before and if I remember correctly the problem would fix itself..? So the NPE's would disappear shortly after such events if I remember correctly. But I removed catching the error/exception in this version because it also caught shader crashes which I didn't want to catch.

Is it possible to 'test' a written shader beforehand (when loading)? That it compiles well and could work well? I think I tried FrameBuffer.compileShader before but it doesn't throw a crash or error..?
Only when the Object3D, which is using the GLSLShader, is visible it'd crash.

I guess I could ignore it for now as it's only one occurrence...
But yeah, just letting you know

Judging from the line in World, which causes the actual problem (1095), there should also be this output somewhere in the log:

Quote

There's a problem with the object list not being consistent during rendering. This is often caused by concurrent modification of jPCT objects on a thread different from the rendering thread!

Are you any chance modifying the world's collection of objects in some other thread like when a touch event happens?

I think that line is only printed with a NullPointerException but I'm not sure about this RuntimeException...

I'm not modifying the world's collection of objects at that point any more... So I am confused...

I don't have access to any other logs however... So I'm puzzled...
I wonder what the Object3D.java:6595 line is all about though

I have tried myself and it should work (usually)...
Though I'd recommend using the 'additional color' variable you can assign to Object3D's, if you only want to use a single color.
Since not all devices allow texture access in the vertex shader stage.
However, these days I believe you can assume most devices do support it.

I don't see anything particularly wrong with it..? But it might be me...

Perhaps you could try playing with this:
Config.defaultCameraFOV = 0.5f; // default = 1.25fMake sure to call this before you're creating your camera/world.

Quote from: AeroShark333 on August 24, 2020, 11:11:19 am

I suppose because the default shaders use an 'unwrapped' for loop, it'd be annoying to change it all.

Yes, I had to do that because using the index from a loop didn't work. I can't remember if in general or only on some devices (more likely), but that's how it is now.

Actually I believe it is generally like that. GLSL doesn't seem to allow non-constant variables for accessing arrays or something. I believe some devices might support it because they've added the support but overall generally not.

Hello,

Whether it fits on the screen or not properly depends on the FOV too.
3 implementations I can think of:
- Complete calculation of where the camera should move to using FOV, bounding box coordinates and screen resolution so it all fits in screen. I believe you can find the ideal position for the camera that way
- Reproject bounding box coordinates to screenspace and see if the coordinates are on the screen or out of the screen. First, you should probably zoom in untill one of the coordinates falls out of the screen size in screenspace. Then zoom out again until all bounding box coordinates are in the screen size in screenspace.
- A little more hacky but to find a correlation between bounding box size (largest distance I'd go for) and zoomfactor. Probably this option is easiest

Good luck

I hope this is helpful