X Ivap Texture Replacement

What is the X-Ivap texture replacement feature?

It's a hack that was added into the X-Ivap branch of libxplanemp and then merged into the swift and xfs branches.

It modifies the OBJ8 command to accept a replacement Albedo and Emissive (Lit) texture map on the end of the line.

Why isn't this accepted in mainline?

There's several problems with the patch.

These 2 texture maps are not the only critical elements in defining the appearance of an OBJ8 model.

Whilst the LegacyCSL (OBJ7) format only used two texturemaps, their interpretation are actually different in OBJ8 (particularly the emissive map - OBJ7 did that very differently).

In addition to the albedo and emissive maps, the model may also have a normal map to control reflectivity or provide fine model detail through lighting tricks, and if there is a normal map provided it too should be varied along with the albedo and emissive maps.

There is no way to do a texture substitution at load time at the moment

Laminar's OBJ8 plugin methods do not provide a way to substitute the texture maps when the object is loaded.

As a result, the patch works by rewriting the OBJ8 file at load-time into a cache directory, modifying the contents of the OBJ8 as it goes.

This whole approach is problematic - apart from the fact this can clobber files if there are bugs in the file handling (particularly as it cleans up the file after it's done), it adds to the load time which is currently enough to stutter the sim as obj8 async aren't working reliably.

We shouldn't be messing with OBJ8 files.

One of the advantages of the OBJ8 format over LegacyCSL is that we now use the same workflows and tools as everybody else in X-Plane, and because they can change at any time without our consultation or involvement, we shouldn't be trying to manipulate them on the fly otherwise we've just created ourselves a compatibility problem.

Given that we can't always roll out a new release of the client with any libxplanemp fixes we want, this is a bad idea in general.

It's not necessary

I honestly don't know what they were thinking - given the effort put into writing the code to modify the OBJ8 on the fly, they could have easily put it into a separate tool that did the work outside of the simulator once, rather than doing it every time time the object is loaded - this would have the distinct advantage that you could test the modified result before shipping it to users, rather than hoping nobody changed anything in libxplanemp that breaks it in the future.

So what is XSB doing?

I (CC) have asked Laminar for an OBJ8 load method that will let us arbitrarily override all textures in the object, not just the two that the X-Ivap authors think we should, with the hope that that will future-proof us against future changes in the model format.

If this comes through, then I'll add the support using load-time modification provided by Laminar, rather than modifying files on the fly.

In the interrim, a tool will be produced that can convert packages that use the 5 argument OBJ8 command to use the standard commands - this tool will be free software and that will protect users against future changes to the format - the tool will be correctable outside of the revision/publishing cycle constraints the pilot clients face.