BatchNode and SimpleBatchNode serialization do not restore correct runtime state after deserialization

[capdevon]

After serializing and deserializing a BatchNode or a SimpleBatchNode using the standard jME Node read/write mechanisms, the internal runtime state is not correctly restored.

Specifically:

If BatchNode.batch() was called before serialization, the deserialized node may contain duplicated children (both the original geometries and previously generated batch geometries).

Internal structures such as batches, batchesByGeom, and related runtime data are not consistent with the scene graph.

The root cause is that batched geometries are runtime-generated and are serialized along with the original subtree, but the internal structures are not reconstructed during read().

[capdevon]

Additional analysis: BatchNode / SimpleBatchNode serialization semantics

After further investigation, the same conceptual issue of InstancedNode appears to affect BatchNode (and SimpleBatchNode) as well.

Even if a custom read() implementation removes serialized batch geometries and calls batch() again, the semantics may still differ from the original state.

The resulting number and structure of batches may not be identical to the pre-serialization state.

This suggests that BatchNode (like InstancedNode) behaves more like a runtime optimization / acceleration structure than a purely logical scene graph node.

For this reason, it may be more appropriate to explicitly declare serialization unsupported for BatchNode by overriding read() / write() and throwing UnsupportedOperationException, rather than attempting to persist and restore a state that is fundamentally derived and runtime-dependent.

    @Override
    public void write(JmeExporter ex) throws IOException {
        throw new UnsupportedOperationException(
                "BatchNode is a runtime-generated structure and does not support serialization."
        );
    }

    @Override
    public void read(JmeImporter im) throws IOException {
        throw new UnsupportedOperationException(
                "BatchNode is a runtime-generated structure and does not support serialization."
        );
    }

Clarifying whether these classes are intended to be persistent scene elements or runtime-only optimization nodes would help determine the correct long-term direction.

[riccardobl]

I've been thinking about this for a while, it might be worth starting to consider that instancing would be better managed at the RenderManager level.
These two "special" nodes always had some kind of weirdness in them.