This is a 'request', in the vain hope mark will no longer use it for bmax's 3d side of things. The .b3d format.
Why?
Firstly, it's very..clumsy/messy to read...no real structure...everything is based on an assumption of 'previous' entries...(Oh this is that type of node, so obviously two nodes back is a mesh...)
and to actually embed mesh data within another set of mesh data..that it is just so...it's torture is what it is...
This might all be second nature to Mark, but it's still confusing. Hell I've finished my .b3d loader, and I'm still not sure of half of it.
Secondly, and most important..the way it handles anims...
Singular surfaces, combined with 'Node' chunks that simply move verts in the original vertex pool.
So surely this is why b3d's are so slow when you animate them, as Mark is transforming them all in memory.
Including dynamic-changing of the data agp aside..or worse, force feed into the gpu per vert.
No support...2 years now, and we still don't have a single decent blitz-side set of support functions for writing and reading them..Hello, earth to Mark? What good is a format no one understands but the few of us patient enough to train ourselfs to a format with no structure as previously mentioned?
This is why we can't/don't have a vertexBone command or similar, as one vertex can be in any node...
These nodes, in another masterstroke, make no reference to any specific surfaces OR triangles...
You can use multiple uv sets of data in a b3d, BUT you can only reference uv set 0 or 1 in the texture part! WHY!?
End of request. ;)
Why?
Firstly, it's very..clumsy/messy to read...no real structure...everything is based on an assumption of 'previous' entries...(Oh this is that type of node, so obviously two nodes back is a mesh...)
and to actually embed mesh data within another set of mesh data..that it is just so...it's torture is what it is...
This might all be second nature to Mark, but it's still confusing. Hell I've finished my .b3d loader, and I'm still not sure of half of it.
Secondly, and most important..the way it handles anims...
Singular surfaces, combined with 'Node' chunks that simply move verts in the original vertex pool.
So surely this is why b3d's are so slow when you animate them, as Mark is transforming them all in memory.
Including dynamic-changing of the data agp aside..or worse, force feed into the gpu per vert.
No support...2 years now, and we still don't have a single decent blitz-side set of support functions for writing and reading them..Hello, earth to Mark? What good is a format no one understands but the few of us patient enough to train ourselfs to a format with no structure as previously mentioned?
This is why we can't/don't have a vertexBone command or similar, as one vertex can be in any node...
These nodes, in another masterstroke, make no reference to any specific surfaces OR triangles...
You can use multiple uv sets of data in a b3d, BUT you can only reference uv set 0 or 1 in the texture part! WHY!?
End of request. ;)