Due to some excellent design, the data persisted for materials and textures is exactly the same regardless of the implemenation class… with the following exception. Unfortunately, the LWJGL-or JOGL-specific implementation class is also saved. This means that restoring the model with either XMLImporter or BinaryImporter will fail if the model happens to have been saved by somebody running with the other type of renderer.
I want to stop writing these implementation classes and use an implementation-class-resolver upon load to instantiate to the type that will work at load-time. The model files will then be renderer-independent, as they should be.
I believe the BinaryImporter/BinaryExporter shouldn't have this issue. There are specialized classes (TextureStateModule, etc) to export these states in renderer independent format.
Momoko_Fan said:
I believe the BinaryImporter/BinaryExporter shouldn't have this issue. There are specialized classes (TextureStateModule, etc) to export these states in renderer independent format.
Thanks very much Momoko.
The problem seems to be that our XML system never incorporated this feature (could have broken at some point, but IMO more likely it was never supported). I tested more thoroughly and find the problem is much more prevalent than I thought (and can be verified by anybody by simply doing an xMLExporterInstance.save()). XMLExporter writes the impl classes for BlendStates, LightStates, WireframeStates, ZBufferStates, cameras, MaterialStates, and TextureStates... well, I think we can assume, all rendering states + cameras at least. When I have time, I'll look into what XMLExporter and XMLImporter (or DOM*Capsules or whatever) are missing.
Fixed w/ rev 4560.
Thanks to tip from Momoko_fan, it was primarily just a matter of plugging the existing BinaryClassLoader into DOMInputCapsule and regression testing.