Ow, argh, bah
(This whole post will be nonsensical to anyone who doesn't work with 3D computer graphics, sorry.)
So our home-grown 3D software at work primarily uses VRML as its native format. Yeah, yeah, it's ancient, but since we're dealing with un-lit textured models it really does everything we need.
The problem with using an old format, though, is that nobody else uses it anymore. So to get data to and from, for example, Poser, I need to implement import/export of something else. Like, say, OBJ (originally Alias/Wavefront's format, now an open standard more or less, though it's also kinda old).
OBJ is kinda wacky in that there is almost no required file structure or order to things. I wrote an exporter for it a while ago, actually, and it was pretty easy - because the format is so loose I can just write stuff out pretty much the same way I did for VRML but with different keywords and formatting, and it all works.
Importing, though. Ugh. Our VRML is assumed to come in shapes, with one texture per shape, and each shape with its own set of vertices and texture coords. Not so in OBJ. Any triangle in the whole file can reference any vertex, any texture coords, and any material/texture. This is not going to be a tweak of the VRML parser. This is going to have to be a whole new class reading in OBJ stuff in one big mess, and then after it's all there I'm going to have to translate and untangle it into independent VRML shapes. What I was hoping to be a one- or two-afternoon job has gotten ugly.
(I imagine there is plenty of OBJ-reading code out there, perhaps even some free for commercial uses, but I have a feeling shoe-horning one of those into our code would take me about as long as writing this.)
(Another option is to punt this and go implement Collada import/export, which we may want to do eventually. But I know nothing about it yet (and because it's new it has 9-hojillion features we don't need), and I need something working for a demo next week. Blargh.)
So our home-grown 3D software at work primarily uses VRML as its native format. Yeah, yeah, it's ancient, but since we're dealing with un-lit textured models it really does everything we need.
The problem with using an old format, though, is that nobody else uses it anymore. So to get data to and from, for example, Poser, I need to implement import/export of something else. Like, say, OBJ (originally Alias/Wavefront's format, now an open standard more or less, though it's also kinda old).
OBJ is kinda wacky in that there is almost no required file structure or order to things. I wrote an exporter for it a while ago, actually, and it was pretty easy - because the format is so loose I can just write stuff out pretty much the same way I did for VRML but with different keywords and formatting, and it all works.
Importing, though. Ugh. Our VRML is assumed to come in shapes, with one texture per shape, and each shape with its own set of vertices and texture coords. Not so in OBJ. Any triangle in the whole file can reference any vertex, any texture coords, and any material/texture. This is not going to be a tweak of the VRML parser. This is going to have to be a whole new class reading in OBJ stuff in one big mess, and then after it's all there I'm going to have to translate and untangle it into independent VRML shapes. What I was hoping to be a one- or two-afternoon job has gotten ugly.
(I imagine there is plenty of OBJ-reading code out there, perhaps even some free for commercial uses, but I have a feeling shoe-horning one of those into our code would take me about as long as writing this.)
(Another option is to punt this and go implement Collada import/export, which we may want to do eventually. But I know nothing about it yet (and because it's new it has 9-hojillion features we don't need), and I need something working for a demo next week. Blargh.)