The merging does nothing to the normals nor does an overlap, at least not on itself. Are these meshes sharing coordinates? You might want to try to call build() on the objects before merging them and not afterwards to see if that helps.

I thought the renderhook solution should have worked as well, but apparently not..?

It should have. Especially in combination with the sort offset, but I guess something interfered with the sorting in some way so that the overlay didn't render at the end, as I though it would. That might happen, the sorting is just a heuristic anyway.

This is the code of setDepth():

public void setDepth(float depth) {
if (depth < Config.nearPlane) {
depth = Config.nearPlane + 1f;
}
this.depth = depth;
}

As you can see, setting it to -infinity has no effect other than setting the depth to Config.nearPlane + 1f

I'm puzzled, why all of my suggestions have no effect. At least the sorting should have helped.

Another idea: Split scene and overlay in two different world instances and render them one after the other with a z-buffer clear in between...

I tried this but it didn't seem to make a difference unfortunately... Any other suggestions?
I believe Overlay#setDepth(-9E30f) sort of works best for now but still not perfectly

That's a bit strange. If the overlay is being rendered last (which should be the case) but you are clearing the depth buffer before rendering, there has to paint over the entire scene no matter what. Have you checked that your implementation gets actually called? The overlay is transparent, I assume? Is there any chance that the object interfering with it is as well?

About the depth thing...that value can't do anything useful, to be honest. A negative value would move the overlay behind the clipping plane, which makes mathematically no sense. Therefor, the method checks, if the value given to it is smaller than the value in Config.nearPlane and if it is, it will auto-adjust it to Config.nearPlane+1. So you can go smaller than Config.nearPlane+1, but you can't go smaller than the actual value in Config.nearPlane. Have you tried playing around with Config.nearPlane itself?

If nothing helps, can you create a test case that shows the problem?

About the enabling/disabling, did you mean Object3D#setVisibility(boolean), World.removeObject(Object3D) or something else? (I assume these are basically the same anyway...)
Does this need to be actively done for every frame (or camera update)? I thought jPCT took care of this automatically based on what's visible inside the camera's view...

Depends on your implementation, I guess. Yes, jPCT takes cares of objects that aren't visible, but it's still faster to disable them in the first place if you are sure that they aren't visible in the current scene. For that, setVisibility() is usually the better option than adding/removing them. In Naroth, it's a bit different. The maps are stored as simple ASCII maps. At load time, I parse the maps and convert the ASCII data into matching beans that contain information about their position, orientation and apperance (a wall, a door, a chest...). When the player moves, I iterate through these objects to see, which ones are potentially visible (the check is rather rough, but good enough). For all that are visible, I assign an actual Object3D to them that gets positioned in the world so that it matches the data in the bean. So basically, I have a pool of Object3D instances which dynamically form the scene. If visualized, this would look like a scene out of a sci-fi movie where the world builds itself as you walk along while it collapses behind you.

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.

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.

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....