q3bsp importer is a pk3 importer, not a bsp importer.

[illwieckz]

Hi, there is a problem with the q3bsp importer, it expects the .bsp to be embedded in a .pk3 archive, and I have not found any assimp_cmd option to import .bsp that is not in a .pk3 archive, meaning the q3bsp importer is not a q3bsp importer but a q3pk3 importer. It's a big difference.

A good use case would be a mapper wanting to load a radiant-made map in blender (using q3map2 to convert the .map to .bsp, then assimp to convert the .bsp to .dae). From a mapper/modeler point of view, it's weird to have to create a temporary extraneous zip to embed the built bsp in, just to allow assimp to convert it.

Also, it means assimp_cmd lacks the ability to import the q3bsp files even if the code to import .bsp file is already there since the pk3 importer needs it.

These lines summarizes the problem very well:

//  Returns true, if the loader can read this.
bool Q3BSPFileImporter::CanRead( const std::string& rFile, IOSystem* /*pIOHandler*/, bool checkSig ) const
{
    if(!checkSig) {
        return SimpleExtensionCheck( rFile, "pk3" );
    }
    // TODO perhaps add keyword based detection
    return false;
}

Q3BSPFileImporter does not import .bsp files but .pk3 files.

So, assimp already knows how to grok the .bsp format, but assimp_cmd can't read .bsp files directly.

[illwieckz]

So, a map-to-dae process is currently:

q3map2 -bsp -meta -patchmeta maps/dumb.map
7z -tzip a dumb.pk3 *
assimp export dumb.pk3 dumb.dae -fcollada

It must be:

q3map2 -bsp -meta -patchmeta maps/dumb.map
assimp export maps/dumb.bsp maps/dumb.dae -fcollada

Also, this q3bsp importer (which is a pk3 importer in fact) exports all the textures from the zip (we just uselessly added to the zip before) giving them new names messing with the whole source tree. So, the q3bsp importer must be renamed to something like "pk3 importer", and a bsp importer is still to be made around the bsp code already written. ;-)

[kimkulling]

Good point. I need to fix that issue!