does anyone have a working model with multiple mesh objects,
or have anything that actually exports lights/cameras for some other project??
I've just finished looking through all the mods I use, and all of the models I've looked at are only a single mesh object...
I don't wanna build something custom just to find out it's not actually standard with Blitz 3D (the problem with poor documentation)
B3D seems to be another one of those fun weird formats like MD5, or PMX...
or the HAL Labs HSD Archive format with less support and reinvented standards. :P
EDIT: if not, I could probably try to see what happens with Brawl Pikachu :P
that's like the only brawl character I have a model for anymore... lol (thanks Western Digital for building cruddy HDDs that blow their head amps)
but down to it's basics, it's only 5 mesh objects with 1 texture each, so B3D shouldn't have a problem with it. ;)
(TEVs aren't handled by DAE conversion, so the smash eyes-don't glow like they should, but that's beside the point)
okay I've just decided to overhaul everything since I've roughly figured out how this format works, and I already hate this format
it's the second worst format next to raw triangles where instead of storing individual vectors and indexing those per vertex
nooooo, instead it just stores the whole vertex (vector data and all) and indexes those per triangle... talk about a waste of data space >.<
because if you have 2 vertices that use different textures for 2 different triangles, you have duplicate vectors with only different UVs
if you're uneducated about 3D as most are, a vertex is simply a single intersection point between 2 or more triangles
like the corner of a cube for example, which is an intersection between 3-6 triangles
what's my argument?
if you have a cube with the same texture on all faces, the B3D format will have 8 vertices total for that mesh
but if just one of those faces has a different texture, that mesh will have 12 vertices
what's the difference when it comes to data size?
well, it's dynamic really, but at most 1 vertex is (3*4)+(3*4)+(4*4)+(8*(2*4))
or 104 bytes
but on average for 1 texture (UV) and no vertex color, that's only 32 bytes (2 lines in a hex editor)
why I'm concerned is because that's (8 or 12) * 32 or (256 or 384) bytes for only the vertices of 1 cube
if you sort that into 12 triangles (B3D doesn't support 6 quads), it gets a bit confusing as it's per brush, but for the simplest single-textured setup that's about
where something more traditionally indexed (like IQM) would be... bigger than I thought for a cube...
448 bytes for the smallest single-textured cube possible... 8 positions, 8 normals, 14 UVs, and 6 quads
520 bytes for the same thing with triangles
why 14 UVs?
it seems bigger now because it's only a cube, but when you get into more complex models (Brawl Pikachu), it's actually quite small as you're not writing duplicate data.
overall though it really doesn't matter much, but I still hate it for being inefficient :P
I guess this is why the good model formats are removed in Minetest-Irrlicht
B3D actually penalizes you by exponentially increasing the filesize for complex models, so the crude joke is to keep models small and cubular.
if that's the case then here's a friendly MS Sam: Thanks I hate it...
if so :D
yep, I was right, B3D is a horrible format -_-*
just tried testing my DarkPikachu model edit from my Minecraft-CustomSteve works...
for just the 3 meshes I exported, the B3D is a preposterous 4.5 MiB (4709497 B)
vs the original (minor TEV edit, extra ~100 bytes) 5 mesh BRMDL/MDL0 at only 170.2 KiB (174276 B)
or heck, how bout the entire FitPikachu00.PAC archive at only 1.1 MiB (1205152 B)
TFW "exponential" is more than just an exaggeration -_-*
and no, my addon doesn't work yet, this is the original addon, nothing is fudged
but tbh, I'm kinda making a big deal over nothing as the engine is probably proper and optimizes things to take much less VRAM than ~4MiB for a single model of ~4000 polygons...
at least I hope so anyways >_>
just for those of you who may have noticed the vertex math had changed and were wondering what's up...
typically most traditional formats will have some sort of weight index within the vertex
but as I started actually going through the code I realized the weight code there only builds the vertex_groups array and doesn't actually write to the file
instead what B3D does is store the groups within the bones, which is still perfectly valid, just not done as often.
for example, Collada DAE is another format that does this ;)
so yeah, just correcting a mistake is all :)
the typical approach though is to do it from the vertices as modern OpenGL uses vertex arrays for up to 4 weight indices/values per vertex-entry ;)
although legacy OpenGL might still benefit a little from bone weights (don't do this, nobody games on Pentium III CPUs anymore, not even me)