Hi all -

I had been previously been trying to rely on some combination of two versions of BLPConverter and BLPLab to convert every blp in the MPQ tree to a png for use in non blizz things.  Unfortunately while they are pretty good there are still certain file types and methods that these tools fail on, making it pretty much impossible to have a toolchain where an engine doesn't complain that stuff is missing.   I'm sure if you have been hardcore into anything with BLPs you'll know how most of the 4-bit alpha textures do not work with the converters available, for example.

Anyway, I got pretty fed up yesterday and wrote a BLP Converter.. it seems to handle all the texture types correctly with my testing so far..  I'd like to release a version of it to the community as a very simple CLI tool.. blah.exe infile outfile, maybe with some options.  Currently I have it writing out to my own .TXR format with mipmaps included.

If you were to have a tool like this, what are the primary outputs you'd want, say besides PNG?  Is that good enough?  What about the other mipmaps beyond the base level?  What about other features?

FYI I'm only testing it with WOTLK data, except for Interface data which is whatever's the latest on bnet.  It seems to work with the newer uncompressed A8R8G8B8 types as well so it might work for all MoP stuff, not sure.   If someone wants to try let me know.  I"d like to find out what bugs might exist as currently I'm just going around the world seeing if anything looks off.  One thing that might need testing is clothing type textures...

Curious about going in the other direction as well (? to BLP).. what do you all use for that and is it okay for your purposes? The above tools seem to work okay for that but I don't do that much.

Would be glad to share the code as well if anyone is interested, PM me.. it's very very small/short/easy.

[note: this refers to 3.3.5 client data]

I am working on a client and server from scratch and have recently gotten to the point where I'm interested in WMO collision (e.g. for the purposes of walking on bridges and such).

I have included the BSP tree data in my conversion to my model, so I'm sure I have all of the LEAF nodes drawing properly.  In this SS of my client I've disabled normal mesh rendering and am drawing only BSP LEAFs - you can see all leaf nodes drawing, each leaf with a random color:

http://24.media.tumblr.com/tumblr_m9wz5ndTrp1rsifdno1_r1_1280.png

The next issue of course is traversing the tree for collision purposes.  Because this is tricky due to coordinate system issues (I'm pretty sure my planes will be different axes than WMO uses), I'm taking my Model Viewer app (separate from client) and have some debug code to draw at the supposed location of each plane.   I use Y-up so I will refer to Y that way.   Several places in WoW data do not, so let's take that into consideration.  I have attempted all sorts of axis swaps in case the BSP tree is different coordinate-wise, but still end up with problems.

For test purposes i'm using the following .WMO that I've converted - in case anyone wants to refer to it:

WMO/Lorderon/Buildings/Ghostlands/Footbridge/Ghostlands_Footbridge.wmo

The start of the tree according to some info on the wiki, is the start of the bounding box.  I call this 'ROOT' with debug text.  Node 0 i would think would refer to the start of the bounding box as well, but actually does not?  The first node is an XZ plane with a distance of -3.0f.  I would expect 0.0f.  Anyway,  because this bridge is basically a 'mirror' image', it wouldn't really make sense to me for the location of the first split plane to have anything other than a height offset from the middle of the bounding box, but I don't know..

I then draw a text indicator with the distance offset being a new plane location in one sepecific axis direction, and so on from there.  You would expect that even by the final leaf nodes, you are still drawing within leaf mini-bounding boxes that are all within the context of the model's geometry itself.  In this video however using this current method of offsets (and any other axis swaps I try) you end up far away from the model coordinates.

http://bh.polpo.org/bsptreefail.wmv

So my question is, is the distance float in each bsp node in the same unit scale as the model?  Is it supposed to be an accumulation of offsets as you traverse the tree?  I assumed so, so the basics of my code do this:

void CModelBspTree::drawNode( CModelBspTreeNode* node, XMFLOAT4 position )
{
std::string planeStr = "";
if( node->planeType == EModelBspNodePlaneType_XY )
{
planeStr = "XY ";
position.x += node->fDistance;
}
else if( node->planeType == EModelBspNodePlaneType_XZ )
{
planeStr = "XZ ";
position.y += node->fDistance;
}
else if( node->planeType == EModelBspNodePlaneType_YZ )
{
planeStr = "YZ ";
position.z += node->fDistance;
}
else if( node->planeType == EModelBspNodePlaneType_Leaf )
{
planeStr = "LEAF ";
assert( node->fDistance == 0.0f );
}

// draw node string and depth @ position

if( node->children[0] < 0 && node->children[1] < 0 ) return;

if( node->children[0] >= 0 )
{
drawNode( nodes[ node->children[0] ], position );
}

if( node->children[1] >= 0 )
{
drawNode( nodes[ node->children[1] ], position );
}
}

Ignoring the axis for a second (the above is just in the middle of trying various combinations, i've obviously tried them all), has anyone attempted to do something similar to debug the positions of bsp locations?

Would be interesting to hear thoughts.