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.

Quote from: AGP on September 26, 2025, 01:47:01 AMThis seems to be software. Am I missing something?

I'm not sure what you mean!?

I'm not of much help here, I'm afraid. I've actually no clue about UI stuff in Java. All I'm usually doing is to open a JFrame/Frame and then draw stuff all by myself.

I dimly remember that others tried to mix an actual UI with the AWTGLCanvas and IIRC, it didn't work our too well (but was possible to a degree). But I couldn't find this thread.

Have you actually tried this approach: https://www.jpct.net/wiki/index226d.html?title=Using_jPCT_in_Swing

I'm not sure what you are trying to achieve. Do you want to switch between a 2D UI and a 3D render or simply between to renders, one software and one hardware?

I tried the latter with the fps example included in the distribution. For me, it worked fine unless I tried to use Java 2D in fullscreen. With that enabled, I ended up with the desktop being rendered 640*480.

I have no influence on how Java 2D and/or LWJGL are handling things, I'm afraid. Have you tried to disable Java 2D's OpenGL/D3D pipeline?

I've moved the question into a new topic, just in case you are wondering.

I'm not aware of a problem with the location of AWTGLCanvas but then again, I've never really used it in situations where it doesn't use the whole frame. So I never tried to use it as part of an actual UI.

Have to tried to disable Java2D's accelerated rendering pipeline? Maybe it's a problem with that (albeit I doubt it, but it might be worth a try).

Nice to see you back in action. Game is still looking great and runs fine in Chrome.

Can you provide a test case that shows that it works uncompiled not not compiled? So that I can see what's actually wrong? I assume that it's a kind of configuration issue, but it's hard to tell without knowing what the actual problem looks like.

How are you applying your animation? In an IVertexController or in some other way?

compile(true) compiles the object to use client side data for the GPU (i.e. it resides in the system's memory) while (false) compiles it to use server side memory (i.e. on the GPU). The former is more suitable for objects that change after compilation while the latter is faster for static objects. Have to tried to compiled it with (true) and indexing disabled?

That's because the GL renderer discards a texture's actual pixel data once it has been uploaded to the GPU. There's a 'keepPixelData()' method in Texture to prevent this.

Yes, a little bit...  It's actually a performance issue. The "old" transparency code is optimized for speed and not accuracy, which is why its results are  not on par with what the GL renderer could do. The alpha stuff has been added much later. It's more flexible but also slower.