Source of what version of which exactly? AWTGLCanvas?

Maybe I can combine the two then into one. I never bothered with shader based shadows in the desktop version. The android version of course uses them, but it uses shaders across the board anyway (because OpenGL ES has no fixed function pipeline anymore). But I never ported that over to the desktop.

Looks a lot like a shader based variant of the ShadowHelper to me. Is it supposed to work like that or is it something different?

You can still access older versions by their version number. Like so: https://jpct.de/download/net/jpctapi_124.zip

Didn't get to it over the holidays. I'll try to look at it later this month.

Yeah, that's a bit strange indeed.

Looks more like some AI hallucination to me. The only part in which jPCT is using GL_SCISSOR_TEST is in the context of render targets, which doesn't apply here.

I'll try to find some time to look into it during the holiday season. Do you actually have a basic test case that shows the issue?

Maybe...I'll have to look into it to see what the overlay code does exactly.

The last change regarding blit was 8 years ago when I moved from int-parameters to floats. No signature change other than that happened. I tried your line with the latest version, it compiles just fine. I'm not sure why you are having issues with it. What part of it is causing which problem exactly?

About the canvas: I don't know, if I even got the issue? Is it that it's somehow shifted to the left when it's supposed to be centered?

I'm not sure what you mean by the missing blit call!? Missing compared to what? Actually, nothing has changed for ages in that regard.

That's because they want you to use Float.valueOf(...) instead of new Float(...) for ... reasons. valueOf() has been added in 1.5, but jPCT is still being compiled to run with 1.4 to make it possible to run the software renderer on really old machines. If that's reasonable or not is another question, but that's how it is for now.
I don't think that they'll ever remove new Float(...), because it will break lots and lots of old code for no reason other than some guy thinks that it's nicer this way. The same applies to finalize(). It's not advised to use it for your own horrifying purposes for at least a decade now, but they haven't provided any other way to clean up stuff before an instance gets garbage collected by the VM, in case the programmer didn't do it.

If you have something to share, I'll be happy to include it.

This should work:

Object3D.mergeAll(new SimpleGlbLoader().loadGlbNoSkin(modelFile).toArray(new Object3D[1]))

Opps, I missed that. I've updated the download, please try again.

I've compiled a new version that includes that change (actually, the code above isn't 100% correct, because it does some changes to the existing code that make no sense, but I've omitted those).

Can you try this one and see if it also fixes your issue: https://www.jpct.de/download/net/jpctapi_133.zip

Quote from: AGP on September 27, 2025, 09:01:49 AMI tried quoting this line, but it didn't show up for some reason:
Have you actually tried this approach: https://www.jpct.net/wiki/index226d.html?title=Using_jPCT_in_Swing

This example seems to be using software rendering.

I don't think so. At the least the text says it's for the AWTGL-Renderer. As mentioned, I've never tried anything like that myself.