Z-enzyme wrote:I'm sorry Jet, but I just don't see any point in doing such a thing. I always used ActorX.
I've used it a lot and it's just perfect for creating unreal mesh files and *.uc files.
A specialized plugin for your choice of modeling program is stellar (for instance, one for Blender would be nice). I'm not gunning against ActorX since it's doing exactly what it needs to do, and very well.
The 3ds2unr source code provides something I wasn't sure was readily available before I found it: the data format for the _d.3d and _a.3d files. Honestly, I was just excited about having and using that information. If anything, I find that a converter is at least just good programming practice.
But I'm also considering, humbly, the areas not covered by ActorX. Blender is tinier, easier to install, and more free than other pieces of software of comparable functionality, give-or-take (many people, including myself, have even used it in a professional capacity). And if, for whatever reason, you wanted to use something like Wings3D, you're in a similar or worse boat.
Blender has an Unreal Skeletal Mesh import/export plugin, but unless we funnel things into a separate 3DS Max install, there's nothing but a flawed, unclear pipeline for getting models into the game's
ORIGNAL vertex model format. It is horrendously frustrating for me when I've followed a really solid set of steps in building, texturing, and animating a model I'm proud of, in Blender, only to be hit by an insurmountable brick wall when I want to convert the bastard over to Unreal. It's debilitating. Having a separate install of Max just to attempt conversion does little to help the situation (though it's not irrational to suggest it).
Being C/C++ capable, having these data layouts paints for me a fairly clear line of action after struggling with my own models. Small, simple, and reliable tool-building isn't a new concept in software design, so instinctively I wanted to jump in and build...
something. In making my own tool, I can also debug the data conversion at convenient points in the process; the most you got out of ActorX and 3ds2unr were log/error messages. Especially for the latter, that doesn't offer much help if the program's mechanics fail to handle unanticipated problems, something that happens stupidly often when you export to .3ds.
I'll also note that my classes/functions so far have been fairly modular. For the most part, I think it could be fairly easy to use parts of my program to alter the conversion process, or change the input format (or even the output format). I'm not doing anything revolutionary with the code, so it might not be all that applicable, but if I end up making the source code public, it may be at least a bit cleaner and more usable than 3ds2unr's code.