A new .b3d is needed
Blitz3D Forums/Blitz3D Programming/A new .b3d is needed
| ||
| 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. ;) |
| ||
| You are joking aren't you? The b3d format is excellent. It can be tricky to master, but that is no surprise considering everything it does. Half the stuff you mention has nothing to do with the format and more to do with the internals of Blitz (and its links to DX7). The tools that support the B3D format are second to none: b3dpipeline, gile[s], Unwrap3D etc. I would like it to support other Blitz entities, cameras, sprites etc. but its not a big problem. |
| ||
| I feel that the .B3D Spec is pretty good really. The problem is that it isn't finished. Not all of what is in the spec is properly implemented (last time I looked anyway, i.e. cameras etc.), although the bone weighting is now in there, which was a recent addition! I'm sure as (the 3D element of) Blitzmax nears completion the .B3D spec will be fleshed out. @Octagon - Exactly what changes would you like to make spec itself? |
| ||
| Mostly structual. Firstly I would like each b3d to be preceded with a entity ID list. And then for each entity to be laid out one by one rather tham embeded into each other. Proper uv support for textures, so we can use more than 2... And lastly, and I agree this more internal which is why I asked for blitzmax, not b3d, the way it lays out animations. You know..I wish I could these things didn't bother me, but writing a true .b3d loader for vivid (As oppossed to one that just 'converted' a blitz one) was probably one of the worst coding experiences of my life. Very frustrating... |
| ||
| Octacon. I don't pretend to be familiar with B3D format so I've no idea whether you have a point or not. But taking this tone "Hello, Earth to Mark" etc.. does not help your arguments. |
| ||
| @Octagon I see. Actually what you are describing is much like the TrueSpace .COB file format. Each object has: ID: ParentID: etc. Which is how the relationships are made up. I remember suggesting this to Mark when .B3D was first in the works, but he felt that structural nesting is more flexible in the long run. When writing the files I'd agree, but for reading it can be a bit more tricky. There again, more people write Savers than Loaders so.. |
| ||
| John, sheer frustration lead me to say that...;) Terra, yeah it makes saving much more natural I agree. But it's not a nice trade-off when it comes to loading. Should be a balence... |
| ||
| After spending sometime writing exporters for other formats I must say that the .B3D format is one of the most ellegent formats around. I feel your above rant is not based on merit but rather than a non-understanding of the format itself. |
| ||
| I know all there is(afaik!) to know about the format, and have a working loading. |
| ||
| As I said, for Exporters it's straightforward stuff. For loaders it's more tricky. Unless you've tried doing both, it's hard to see it both ways. |
| ||
| What's so hard about loading? Isn't the nesting a simple hierarchy? Excuse my ignorance but it seems straightforward both ways to me... |
| ||
| The .b3d format is probably the most convoluted mesh format I have ever worked with, with the exception of Unreal engine packages. |
| ||
| From what you describe I would think it would be easy to write a .b3d to xml, xml to .b3d converter to make it easier to understand for the uninitiated. |
| ||
| I was writing the 3DWS b3d exporter, and just wanted to complain. |
| ||
| From what you describe I would think it would be easy to write a .b3d to xml, xml to .b3d converter to make it easier to understand for the uninitiated. It would? Are you sure? :) http://www.blitzbasic.com/codearcs/codearcs.php?code=665 |
| ||
| I was missing a documentation for dummies like me about all aspects of the format, including and especially about animation. I don't want to hack my way trough the format that's why I never tried to write an Animation Export code so far. And I really miss this in the code archives. I still don't know how this works and I am not planing to purchase TweakB3D only to get some File Format infos. |
| ||
| Something I would really like to see in future versions of the B3D format is an XREF node that purely references an external mesh in whatever format (B3D, X, whatever). Its position/scale etc would be held in its parent NODE. |
| ||
| The .b3d format is excellent. We just need to establish a standard for custom node types. @jfk - if you look at Peter's xml2b3d (link above) you will see how to import/export animation ! |
| ||
| I like the b3d file format - very simply laid out and chunk based so that you can add to it without breaking it. I too have written importers and exporters for the .b3d file format. I think basically if you don't like it, you don't have to like it - you can use .x or even write your own. It is fairly blitz centric - but then it is the blitz 3d file format. I am hoping though, that mark does away with the ridiculous notion of surfaces in Blitzmax. re: xrefs - mark once said a couple of years ago in an email to me that he'd be interested in xref stuff, that is - you have one mesh in memory and the engine optimises for this when it's used several times. The real power of xrefs would be for detail objects in games like quake3. This is where the lighting is usually baked with the object (1 or 2 uv channels) then the object, self contained is added to the level and x-referenced. It's only one object in the file format but many in game. Obviously they need to be pre-baked and pre-lightmapped and you can't lightmap them once you've positioned them. It's uses are definately worth having in the file format. |
   |