Regarding the objects clipping through, I'm not entirely sure how to fight this. I see why it happens but I've never seen this happen to me. There's a kind of hack that you might want to try to see if that does help:

• create the overlay as usual
• user Oyerlay.getObject3D() to get the internal Object3D from the overlay
• attach an IRenderHook implementation to that object, that...
• ...implements IRenderHook.beforeRendering(<int>) in a way that FrameBuffer.clearZBufferOnly() is being called in it.
• ...and then check what this does...

About the merging: It's the usual trade-off, I guess. Merging them requires time at startup (not sure if that matters here) and consumes more memory, because it limits the ability to share meshes. On the other hand, it uses less draw calls, which should make it render faster. Apart from that, the basic idea sounds fine to me. It would have done it the same way (maybe that doesn't say much, but anyway...). In fact, I did something very similar with the dungeons in Naroth. They aren't a solid mesh but consist of building blocks for walls, ceilings and floors that are constantly enabled, disabled and moved around when the player moves. Of course, that's slower than a single mesh but it's actually fast enough and requires much less memory and is more flexible.

The overlay is part of the scene, because it's actually a 3d object which has a real depth and read/writes from/into the depth buffer. But they are rendered after everything else. It actually shouldn't happen that objects clip through them, but it might be an accuracy issue. Depth buffers, especially on mobile, aren't very accurate at times. It might help to move the clipping plane into the scene a little more. Do you have a screen shot of how this looks?

About the objects: I'm not sure, if I got you correctly here. You can't merge two objects when one is static and one is dynamic. The result will either be 100% static or 100% dynamic, depending on your setting for the merged object. In any case, you can't animate the dynamic "part" of it independently from the other objects that share the same mesh.

Quote from: AeroShark333 on November 07, 2021, 01:25:52 AM
If I remember correctly, I got black textures on some devices when using either non-square (but still POT) or NPOT textures. I believe the only way I could force to make it work was to first convert it/stretch it to a POT square texture... But yeah, memory... So I believe I didn't try to bother to go into it that much anymore

Yes, that's an issue indeed. It's a driver/hardware limitation, not jPCT-AE's fault. It shouldn't be a problem on any modern hardware though.

Quote from: AeroShark333 on November 06, 2021, 08:52:36 AM
I don't think shaders would mind additionalColor to be negative valued

That depends on the graphics chip. Some don't mind and just clip the values below 0 and larger than 1, some render everything dark and some so crazy. One could do the clipping in the shader and/or in the code (for the fixed function pipeline, which still exists) but that would decrease performance (albeit it shouldn't be that much of an issue). But it would break compatibility with desktop jPCT, because on that one, RGBColor extends AWTColor (I don't know the reason anymore, but I'm sure that there was one... ) and that doesn't support it.

Quote from: AeroShark333 on November 06, 2021, 08:47:20 AM
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....

Maybe that's the best approach after all. Just take a fitting default shader and modify it to do what you want. After all, you might want to do that anyway, because the specular implementation actually isn't that great IIRC and more of an afterthought. I didn't really expect it to be used by anybody, to be honest...

The changes that you suggested would partly break compatibility with desktop jPCT as well.

Are you using your own shaders or the default ones?

The lookAt()-method is prone to this flipping issue, because of the way in which the algorithm works. There's another method in Matrix that might help:

https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Matrix.html#setOrientation-com.threed.jpct.SimpleVector-com.threed.jpct.SimpleVector-

Assuming that you have the direction vector and also have/can create the matching up vector, it returns a rotation matrix, that aligns an object with these vectors. If you invert this matrix, you get something that you can feed into the camera as a view matrix using setBack(<Matrix>)...I guess...

Quote from: Kumaraswamy on October 24, 2021, 04:53:12 PM
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.

Looks stunning.

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.

You have to enable collisions on the object to be registered. Maybe this helps: https://www.jpct.net/wiki/index.php?title=Collision_detection

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.

"It behaves weirdly" doesn't really mean much. I can't possibly help based on this alone. Can you provide more details about what's going on exactly?

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.