Could be asleep, typing random messages instead.

An Ideal Remedy for 3ds2unr

For questions and discussion about UnrealEd, UnrealScript, and other aspects of Unreal Engine design.

Moderators: ividyon, Semfry, zYnthetic

Z-enzyme
White Tusk White Tusk
Posts: 2135
Joined: 13 Nov 2007, 20:01

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 31 May 2016, 09:57

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.

User avatar Jet v4.3.5
Skaarj Elder Skaarj Elder
Posts: 1239
Joined: 24 Dec 2007, 17:40
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 31 May 2016, 20:29

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.
Image
ModDb Portfolio
"Bear," she cried. "I love you. Pull my head off."

User avatar AlCapowned
Skaarj Warlord Skaarj Warlord
Posts: 861
Joined: 19 Dec 2009, 22:25

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 31 May 2016, 21:05

Z-enzyme wrote:I always used ActorX. I've used it a lot and it's just perfect for creating unreal mesh files and *.uc files.


It's perfect for skeletal meshes, but it's awful for vertex meshes since it always makes them tiny (and extremely jiggly by extension) no matter what the scale value is set to.

The other Unreal-mesh creating tools like U3D are okay, but they have problems of their own, so I'm happy for any alternative I can get.

Z-enzyme
White Tusk White Tusk
Posts: 2135
Joined: 13 Nov 2007, 20:01

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 31 May 2016, 21:57

AlCapowned wrote:
Z-enzyme wrote:I always used ActorX. I've used it a lot and it's just perfect for creating unreal mesh files and *.uc files.


It's perfect for skeletal meshes, but it's awful for vertex meshes since it always makes them tiny (and extremely jiggly by extension) no matter what the scale value is set to.

The other Unreal-mesh creating tools like U3D are okay, but they have problems of their own, so I'm happy for any alternative I can get.


I must disagree... Unreal has this "thing" of optimizing vertex meshes to 0.8 units. Or 0.08, can't remember really. All of your meshes that you export using Actor X vertex exporter has to sit in a box of 2048x2048x1024... But, as an output size.

So, you can make huuuge mesh, then export it with ActorX's uniform scale scaled down, this uniform scale also scales this 0.08 optimization. So, if you have a mesh which has 4096x4096x2048 bounding box then you can use uniform scaling of 0.5 to fit it inside 2048x2048x1024 and get this optimization thingy scaled to 0.04.

Yep, this works. I never, absolutely never used any other exporting program for vertex meshes. And I did a lot of them (all of the Alternate Pawns for example). It does it's job well.

User avatar AlCapowned
Skaarj Warlord Skaarj Warlord
Posts: 861
Joined: 19 Dec 2009, 22:25

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 01 Jun 2016, 15:38

Huh, I didn't know it worked that way. Is the scale value limited to anything between 0 and 1 then? I remember putting in huge values for it that did nothing.

Good stuff to know, though.

Z-enzyme
White Tusk White Tusk
Posts: 2135
Joined: 13 Nov 2007, 20:01

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 01 Jun 2016, 22:20

Can't remember correctly but it did work that way. Or you had to keep the mesh inside 2048x2048x1024 and then scale it down with X,Y,Z *.uc import script... Hell, I can't remember. Anyway, you could get quite decent accuracy there.

Might consider making a tutorial then.

But still, Jet, I see your point there I guess. Having a separate 3DS Max install if you use Blender is just... Waste of space.

User avatar Jet v4.3.5
Skaarj Elder Skaarj Elder
Posts: 1239
Joined: 24 Dec 2007, 17:40
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 02 Jun 2016, 08:18

Z-enzyme wrote:Can't remember correctly but it did work that way. Or you had to keep the mesh inside 2048x2048x1024 and then scale it down with X,Y,Z *.uc import script... Hell, I can't remember. Anyway, you could get quite decent accuracy there.

Might consider making a tutorial then.

But still, Jet, I see your point there I guess. Having a separate 3DS Max install if you use Blender is just... Waste of space.


This talk about the scaling weirdness is interesting. The coordinate limitations in Max may be there to accommodate some internal step during ActorX export, and/or to work around a certain obstacle present in Max's own coordinate system. I know the vertex coordinates in the _a.3d are strictly limited to -128.0 to +127.0 due to their binary encoding (a neat process that compresses the X, Y, and Z coordinates into a single 32 bit data value). If I can automate the scaling precision process, that would greatly improve the tool's ease of use while also improving vertex precision.

It would be fairly simple to run the model data through a maximization function that scales it to fit the total available cubed space before encoding and writing the *.3d files. I could then automatically write the inverse scale settings in the exported .uc file. I'm probably going to do that, and offer it up as an option if the .config/.ini system plays out. If I'm crazy enough, I might also implement something that really improves precision -a function that translates the model so that its center lies in the center of the bounds cube- and then I could scale the model to those bounds. Ideally, if you can reverse the translation and the scale in the exported .uc, this would would result in optimal coordinate precision in-engine like what you're referring to.
Image
ModDb Portfolio
"Bear," she cried. "I love you. Pull my head off."

Z-enzyme
White Tusk White Tusk
Posts: 2135
Joined: 13 Nov 2007, 20:01

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 02 Jun 2016, 10:35

Are you going tu build some kind of GUI for that app? If so, it would be a good idea to add a list of animations to exported *.uc.

As it comes to ActorX and scale, I'll check it out how it works exactly.

User avatar Jet v4.3.5
Skaarj Elder Skaarj Elder
Posts: 1239
Joined: 24 Dec 2007, 17:40
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 02 Jun 2016, 23:27

Z-enzyme wrote:Are you going tu build some kind of GUI for that app? If so, it would be a good idea to add a list of animations to exported *.uc.

As it comes to ActorX and scale, I'll check it out how it works exactly.


While I appreciate good GUI tools, I'm not going to try at this point. I think I'm going to offer stat-printing in the console, at least as an option, on or before export. This would include a list of sequences and their lengths, and anything else that seems relevant or important.

The GUI thing has some problems. 1) I don't have the experience with writing them, so I'd end up writing a bad one anyway, and 2) if a smaller console application like this converter has a good interface (e.g. not 3ds2unr), then I think the process is more straightforward than a GUI program.

For example, if I already have my conversion tool open and I'm navigating through a GUI to open my files, edit or alter them, and export them, then I may spend about 11 seconds on one model. On the other hand, if I have a single-step run of the conversion process, or drag-and-drop, and my preferences are stored away in a .config file so I don't have to think about that each time I run the program, then I can push at least twice as many models out in those 11 seconds since the process requires a single action from the user.
Image
ModDb Portfolio
"Bear," she cried. "I love you. Pull my head off."

User avatar Jet v4.3.5
Skaarj Elder Skaarj Elder
Posts: 1239
Joined: 24 Dec 2007, 17:40
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 10 Aug 2016, 06:34

So I've made some small (but major) progress with this converter. At the moment, I have .obj importing, limited Unreal model format data packaging, and export working at a simple capacity. A test result is shown below, from a .obj file exported from Blender:



My next goal is to get texture mapping and individual texture groups implemented in some way. Once I get much of the core pipeline implemented at a crude working level, I'll prioritize cleanup and robustness passes on the current code, and try to get a build put together that people can play around with for still, single-frame meshes.

After that I'll start thinking about the large task of planning and implementing the animated mesh importing code. This may or may not include animation append functionality, which in itself is a bit of a challenge. I'll have to see what I can get working. If it's possible, I may also start programming the configuration file system while working on the other priority tasks above.

I might not get around to a lot of this too quickly since I'm busy, but considering the free time I get, it's coming along at a decent rate.
Image
ModDb Portfolio
"Bear," she cried. "I love you. Pull my head off."

User avatar Jet v4.3.5
Skaarj Elder Skaarj Elder
Posts: 1239
Joined: 24 Dec 2007, 17:40
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 18 Aug 2016, 20:04

I helped UBerserker out some time recently in separating the Skaarj mothership from the terrain in Demon Crater, so I had a model on hand to test for texture mapping and groups.

Here is the model in-game:


What you see here is not exactly what it looks like, at least from a distance.

While getting the model back into Ued as a brush is fairly straightforward, a problem arises when dealing with Unreal's texture coordinates for vertex models. When we pan, rotate, and scale our brush textures in Unreal, we're essentially adjusting internal UV coordinates that permit the crossing of boundaries, which is why textures tile. In your 3D modeler of choice, it's likely you can reliably move your UVs around as you please, crossing boundaries either for intentional placement or while editing. The texture will be wrapped around in a natural way as your triangles are moved.

In Unreal, UV coordinates are ALWAYS 0 to 255, and thus have limits that aren't present in most modeling software. UVs that are outside the main UV grid in a modeling program are easy to slide onto the main UV texture space within the converter. This is fine, but for Unreal's vertex model format, no individual triangles can cross major UV texture boundaries. The mothership model presented a problem when trying to convert to a vertex mesh, since its textures were aligned with tiling in mind. As a vertex mesh, textures were skewed horribly on the converted model once I loaded it into the game.

To account for this, I re-unwrapped the model's UVs to fit into the main UV texture space. I then baked the original Unreal textures onto a new texture matching the new UVs. This ensures that none of the triangles cross a texture boundary, and thus conversion works the way we expect.

Here's the single texture, baked from the original texture mapping:



This was a demonstration not just of the triangle boundary limitation, but also that the converter properly converts texture coordinates. Since most of this is working, I plan on prepping an executable for drag and drop conversion of a single .obj file with a single one-frame animation. I'm hoping to get that posted here soon.
Image
ModDb Portfolio
"Bear," she cried. "I love you. Pull my head off."

User avatar Gustavo6046
Skaarj Scout Skaarj Scout
Posts: 20
Joined: 09 Apr 2016, 14:35
Location: Porto Alegre, Rio Grande do Sul, Brazil
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 25 Aug 2016, 00:59

Blast from the past, but as I did make my working Blender exporter (to brush), I might retry it -- this time, to MESH!

As for the individual texture groups, you might set custom properties in faces in Blender and set it to the name of the texture. Used textures are put in a list, and they are exported from Blender, along with the list index of those texture names.

EDIT: I've read the entire File Format documentation a thousand times, but I can't figure out why I can't export from Blender a good mesh... :/

Anyways, not for this topic so I'm gonna get off. I can't get it to work... :cry:
This is the 700th member!

Half-veteran modeller. Sucker at gaming. Quite nice at coding. O.K. at texturing. Good at mapping in general.

What else do you need? :)

User avatar Gustavo6046
Skaarj Scout Skaarj Scout
Posts: 20
Joined: 09 Apr 2016, 14:35
Location: Porto Alegre, Rio Grande do Sul, Brazil
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 27 Sep 2016, 00:50

Do you know? I jettison Python. I'm gonna use pure C++ power to do the perfect obj2unr. Basically get a .obj file via stdin, output a .3d file into stdout, and log into stderr. Perfect ^_^
This is the 700th member!

Half-veteran modeller. Sucker at gaming. Quite nice at coding. O.K. at texturing. Good at mapping in general.

What else do you need? :)

User avatar Gustavo6046
Skaarj Scout Skaarj Scout
Posts: 20
Joined: 09 Apr 2016, 14:35
Location: Porto Alegre, Rio Grande do Sul, Brazil
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 29 Sep 2016, 00:20

Ok so now I'm gonna post the source code for the sake of it!
main.cpp

Code: Select all

#include <iostream>
#include <vector>
#include <fstream>
#include <cstdlib>
#include <cstring>

#include "mesh.hpp"
#include "export.cpp"
#include "ssplit.cpp"

using std::cout;
using std::cin;
using std::vector;
using std::string;
using std::pair;
using std::ifstream;
using std::stringstream;
using std::strcmp;

struct stats
{
    unsigned int parsedlines;
    unsigned int parsedverts;
    unsigned int parseduvs;
    unsigned int parsedfaces;
    unsigned int totallines;
};

bool parseObjLine(string line, mesh* out, stats* out_stats)
{
    face newface;
    vector<double> curd;
    vector<string> pieces;
    string cur = "";

    // Split lines with space delimiter
    for ( unsigned int i = 0; i < line.size(); i++ )
    {
        if ( line[i] == ' ' )
        {
            pieces.push_back(cur);
            cur = "";
        }

        else
            cur += line[i];
    }

    if ( cur != "" )
        pieces.push_back(cur);

    // Check if vertex; if so, append to mesh vertex list
    if ( line.find("v ") == 0 )
    {
        if ( pieces.size() < 4 )
            return false;

        for ( unsigned int i = 0; i < 3; i++ )
            curd.push_back(strtod(pieces[i + 1].c_str(), 0));

        out->vertices.push_back(curd);

        out_stats->parsedverts++;
        return true;
    }

    // Check if texture UV vertex too
    else if ( line.find("vt") == 0 )
    {
        if ( pieces.size() < 3 )
            return false;

        for ( unsigned int i = 0; i < 2; i++ )
            curd.push_back(strtod(pieces[i + 1].c_str(), 0));

        out->uv.push_back(curd);

        out_stats->parseduvs++;
        return true;
    }

    //...and for faces
    else if ( line.find("f") == 0 )
    {
        if ( pieces.size() < 4 )
            return false;

        vector< vector<int> > indexes;
        vector<string> indexlist;
        string curr = "";

        for ( unsigned int i = 1; i < pieces.size(); i++ )
        {
            indexlist.clear();
            curr = "";

            for ( unsigned int j = 0; j < pieces[i].size(); j++ )
            {
                if ( pieces[i][j] == '/' )
                {
                    indexlist.push_back(curr);
                    curr = "";
                }

                else
                    curr += pieces[i][j];
            }

            if ( curr != "" )
            {
                indexlist.push_back(curr);
            }

            vector<int> new_index;

            new_index.push_back(atoi(indexlist[0].c_str()));
            new_index.push_back(atoi(indexlist[1].c_str()));

            indexes.push_back(new_index);
        }

        for ( int i = 0; i < 3; i++ )
        {
            newface.vertices[i] = indexes[i][0];
            newface.uv[i] = indexes[i][1];
        }

        out->faces.push_back(newface);

        out_stats->parsedfaces++;
        return true;
    }

    return false;
}

int main(int argc, char* argv[])
{
    anim animation;
    mesh model;
    stats statistic;

    // Title :3
    cerr << "===================================\nOBJ2UNR: Wavefront Converter for Unreal Engine 1\n\n   - by Gustavo6046 (Gustavo R. Rehermann)\n===================================\n\n";

    if ( argc < 4 )
    {
        if ( argc > 1 && strcmp(argv[1], "-txt") == 0 )
        {
            cerr << "The framelist (text file of any extension passed through stdin) must contain the relative or absolute path of each .obj file used as frames for the model.\ne.g.:\n\na.obj\nb.obj\nc.obj\n\nwould import three frames:\n\n1 -> a.obj\n2 -> b.obj\n3 -> c.obj\n\nin the order they have been put in the .txt project. You can use third-party tools to automate the task of creating the .txt file :^)\n     -Gustavo\n";

            return 0;
        }

        cerr << "Syntax: obj2unr *aniv name* *data name* *name of .txt file; see `obj2unr -txt` for more*\n";

        return 4;
    }

    string fnam;
    string line;

    ifstream otxt;
    otxt.open(argv[3]);
    std::getline(otxt, fnam);

    ifstream currfile;
    currfile.open(fnam.c_str());

    for (; std::getline(otxt, fnam) && currfile; )
    {
        // clean statistics
        statistic.parsedlines = 0;
        statistic.parsedverts = 0;
        statistic.parseduvs = 0;
        statistic.parsedfaces = 0;
        statistic.totallines = 0;

        // parse each of these FREAKING LINES
        for (; std::getline(currfile, line);  )
        {
            if ( parseObjLine(line, &model, &statistic) )
                statistic.parsedlines++;

            statistic.totallines++;
        }

        // add frame to animation
        animation.frames.push_back(model);

        if ( animation.frames.size() < 2 )
            animation.polys = model.faces;

        // log statistics
        cerr << "Imported model '" << fnam << "': Parsed " << statistic.totallines << " lines (" << statistic.totallines - statistic.parsedlines << " lines skipped), with " << statistic.parsedverts << " vertices, " << statistic.parseduvs << " UV coordinates and " << statistic.parsedfaces << " faces.\n";

        // open new file
        currfile.close();
        currfile.open(fnam.c_str());
    }

    currfile.close();

    if ( animation.frames.size() <= 0 )
    {
        cerr << "Error: Invalid model imported! (No imported frames detected!)";

        return 1;
    }

    if ( animation.polys.size() <= 0 )
    {
        cerr << "Error: Invalid model imported! (No polygons!)";

        return 2;
    }

    if ( animation.frames[0].vertices.size() <= 0 )
    {
        cerr << "Error: Invalid model imported! (No vertices in first frame!)";

        return 3;
    }

    for ( unsigned int i = 0; i < animation.polys.size(); i++ )
    {
        for ( unsigned int j = 0; j < 3; j++ )
            if ( animation.polys[i].vertices[j] > animation.frames[0].vertices.size() )
            {
                cerr << "Error: Invalid model imported! (Face's vertex index out of range!)";

                return 5;
            }

        for ( unsigned int j = 0; j < 2; j++ )
            if ( animation.polys[i].uv[j] > animation.frames[0].uv.size() )
            {
                cerr << "Error: Invalid model imported! (Face's UV index out of range!)";

                return 6;
            }
    }

    double real_scale;
    real_scale = 16;

    export_model(&animation, argv[1], argv[2], &real_scale);
    cerr << "Done converting model!";
}


mesh.cpp

Code: Select all

#ifndef MESH_HPP_INCLUDED
#define MESH_HPP_INCLUDED

#include <vector>
using std::vector;

struct face
{
    unsigned short uv[3];
    unsigned short vertices[3];
};

struct mesh
{
    vector<face> faces;
    vector< vector<double> > vertices;
    vector< vector<double> > uv;
};

struct anim
{
    vector<face> polys;
    vector<mesh> frames;
};

#endif // MESH_HPP_INCLUDED


umesh.cpp

Code: Select all

struct unrealpolyh
{
    unsigned short NumPolygons, NumVertices;
    static const unsigned short UnusedS[2];
    static const unsigned long UnusedL[7];
    static const unsigned char UnusedC[12];
};

struct unrealpoly
{
    unsigned short mVertex[3];
    static const char mType = 1;
    static const char mColor = 128;
    unsigned char mTex[3][2];
    static const char mTextureNum = 0;
    static const char mFlags = 0;
};


export.cpp

Code: Select all

#include "mesh.hpp"
#include "umesh.cpp"
#include <iostream>
#include <fstream>
#include <vector>
#include <sstream>
#include <cstring>

using std::cerr;
using std::ofstream;
using std::vector;
using std::stringstream;
using std::string;
using std::strcmp;

unsigned long unreal_vertex(double coord[3])
{
    unsigned long result;

    result =   ( int(coord[0] * 8.0) & 0x7ff ) |
            ( ( int(coord[1] * 8.0) & 0x7ff ) << 11 ) |
            ( ( int(coord[2] * 4.0) & 0x3ff ) << 22 );

    vector<void*> fmt;
    fmt.push_back(&coord[0]);
    fmt.push_back(&coord[1]);
    fmt.push_back(&coord[2]);
    fmt.push_back(&result);

    return result;
}

unrealpoly poly_from_face(face other, mesh* base)
{
    unrealpoly res;

    for ( unsigned int i = 0; i < 3; i++ )
        for ( unsigned int j = 0; j < 2; j++ )
            res.mTex[i][j] = base->uv[other.uv[i] - 1][j] * 255;

    for ( unsigned int i = 0; i < 3; i++ )
    {
        if ( other.vertices[i] - 1 >= 0 )
            res.mVertex[i] = other.vertices[i] - 1;

        else
            res.mVertex[i] = base->vertices.size() - other.vertices[i];
    }

    return res;
}

void export_model(anim* outmodel, char* aniv_name, char* data_name, double* oscale)
{
    double scale;

    if ( oscale == NULL )
        scale = 1;

    else
        scale = *oscale;

    cerr << "Writing data file...\n";
    // export data
    unrealpolyh header;

    header.NumPolygons = outmodel->polys.size();
    header.NumVertices = outmodel->frames[0].vertices.size();

    FILE *fdata;
    fdata = fopen(data_name, "wb");

    fwrite(&header, sizeof(unrealpolyh), 1, fdata);
    cerr << "Wrote data header!\n";

    unrealpoly poly;

    for ( unsigned int i = 0; i < outmodel->polys.size(); i++ )
    {
        poly = poly_from_face(outmodel->polys[i], &outmodel->frames[0]);

        fwrite(&poly, sizeof(unrealpoly), 1, fdata);
    }

    cerr << "Wrote data file!\n";

    fclose(fdata);

    // export anim (aniv)
    cerr << "Writing aniv file...\n";

    FILE *faniv;
    faniv = fopen(aniv_name, "wb");

    // -header...
    short numverts = outmodel->frames.size();
    fwrite(&numverts, sizeof(short), 1, faniv);

    short framesize = header.NumVertices * sizeof(unsigned long);
    fwrite(&framesize, sizeof(short), 1, faniv);

    cerr << "Wrote aniv header!\n";

    // -...and vertexes!
    mesh* frame;
    double coord[3];
    unsigned long uvert;

    for ( unsigned int i = 0; i < outmodel->frames.size(); i++ )
    {
        frame = &outmodel->frames[i];

        for ( unsigned int v = 0; v < frame->vertices.size(); v++ )
        {
            for ( unsigned int j = 0; j < 3; j++ )
                coord[j] = frame->vertices[v][j] * scale;

            uvert = unreal_vertex(coord);
            fwrite(&uvert, sizeof(unsigned long), 1, faniv);
        }
    }

    fclose(faniv);

    cerr << "Wrote aniv file! Wrote " << outmodel->frames.size() << " frames and " << frame->vertices.size() << " vertices.\n";
}


A lot of code isn't it! :P I'm not too good with C++...
This is the 700th member!

Half-veteran modeller. Sucker at gaming. Quite nice at coding. O.K. at texturing. Good at mapping in general.

What else do you need? :)

diamond
Skaarj Berserker Skaarj Berserker
Posts: 366
Joined: 13 Nov 2007, 10:51
Location: ROFLand
Contact:

Subject: Re: An Ideal Remedy for 3ds2unr

Post Posted: 29 Sep 2016, 13:47

Can it produce hard edges by duplicating vertices? ActorX does have such feature.
Image
UBerserker wrote:Architecture doesn't need to detailed, it just needs to be right.

Previous Next

Who is online

Users browsing this forum: No registered users and 5 guests