Spring RTS Engine

Posted: **25 Jan 2010, 22:51**

Obj keeps the normals a fixed obj sub object import would solve this whole discussion

That's certainly true, and would probably be easier.

OK, read over the Wavefront OBJ code in UpSpring.

It doesn't handle the "g" (group) definition at all:

Code: Select all

static int line_type(char *line)
{
 char *cmd;
 cmd = strtok(line,whitespace);
 if (!cmd) return(COMMENT);
 if (!strcmp(cmd,"v")) return(VERTEX);
 else if (!strcmp(cmd,"vn")) return(NORMAL);
 else if (!strcmp(cmd,"vt")) return(TEXTURE);
 else if (!strcmp(cmd,"l")) return(LINE);
 else if (!strcmp(cmd,"f")) return(FACE);
 else if (!strcmp(cmd,"fo")) return(FACE);
 else if (!strcmp(cmd,"mtllib")) return(MTLLIB);
 else if (!strcmp(cmd,"usemtl")) return(USEMTL);
 else if (!strcmp(cmd,"maplib")) return(MAPLIB);
 else if (!strcmp(cmd,"usemap")) return(USEMAP);
 else if (!strcmp(cmd,"#")) return(COMMENT);
 return(UNSUPPORTED);
}

All it really needs (I think) is to read from one "g" to another, or if it doesn't find any at all, then import the piece as one mesh.

So, basically, iterate through the file at the start, look for "g "..SomeName, and if # g > 1, then read from g to next g (OBJ is organized by group) and return the geometry as a named Piece using the group name.

I really wish I read C++ a bit better. This looks like a 30-minute problem, tbh. Here's the relevant source.

Spring RTS Engine

obj vs 3ds when importing into upspring

Re: obj vs 3ds when importing into upspring