View topic - ANN: OBJ model format support


All times are UTC + 1 hour


Post new topic Reply to topic  [ 121 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next
Author Message
PostPosted: 28 Mar 2010, 22:26 
Spring Developer

Joined: 08 Oct 2006, 15:58
Starting with the next major engine release, Spring will be able to natively load (a subset of) Wavefront's OBJ model format specification. To make this work within Spring's model animation framework, the engine needs a small amount of per-model metadata about the piece hierarchy, which must be provided separately by a Lua script. These scripts can be auto-generated for S3O's (should you wish to convert them) or written by hand, though if you can, you'd probably be better off coding up a simple plugin for your 3D modeller to do that. As an example, here is one of MrD's older S3O models dressed up in OBJ clothes:

Attachment:
core_commander.obj.lua [4.29 KiB]
Downloaded 300 times

Attachment:
core_commander.obj.txt [488.61 KiB]
Downloaded 313 times


(Put both these files in the objects3d/ directory of your mod/game and remove the .txt extension if you want to test with an upstream Spring build, then reference the .obj via the objectname key in a unit's .fbi/.lua definition.)

For the time being, OBJ's get rendered in (almost) exactly the same way that S3O's are, so they must have a primary and secondary texture. This may change in the future if the format is picked up.

Finally, the current limitations (also read the .lua notes) are:

    * each vertex MUST have a normal and texture-coordinates
    * each face MUST be a triangle (exactly three vertices/normals/texcoors)
    * a piece (in 3DO/S3O terms) MUST be a named object in an OBJ model
    * groups, smoothing groups, and materials are not supported yet
    * triangles must have counter-clockwise winding order

Blender plugin to generate the metadata script automatically (again remove the .txt extension and place it in your Blender scripts/ directory) is here, version 1.3:
Attachment:
SpringOBJMetaDataScriptExporter.py.txt [9.77 KiB]
Downloaded 184 times


Last edited by Kloot on 05 Sep 2012, 10:54, edited 11 times in total.
Top
 Offline Profile  
 
PostPosted: 28 Mar 2010, 23:15 
Moderator
User avatar

Joined: 23 Nov 2005, 06:16
Location: Dunedin, New Zealand
This is relevent to my interests, but what is a group in obj? If I select a number of objects and 'combine' them (I only know the wings command), is that a group or a single object?
Top
 Offline Profile  
 
PostPosted: 28 Mar 2010, 23:46 
Spring Developer

Joined: 08 Oct 2006, 15:58
You'd have to inspect the .obj exported by Wings after issuing such a command, I'm not really familiar with it. Look for lines starting with "o " and "g " (the engine will ignore the latter).
Top
 Offline Profile  
 
PostPosted: 29 Mar 2010, 01:07 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
Awesome.

A small request. Can this please be changed to look for unitname.lua instead or unitname.obj.lua. The metadata really shouldn't be tied to the format like that, since it will mean renaming them all if you change model format.

Also curious how you got all the values, particularly the offsets. Have you written an s3o converter already?
Top
 Offline Profile  
 
PostPosted: 29 Mar 2010, 12:02 
Moderator
User avatar

Joined: 06 Aug 2005, 12:15
Whats the advantage of using .obj instead of .s3o?
Top
 Offline Profile  
 
PostPosted: 29 Mar 2010, 12:03 
Modeler
User avatar

Joined: 28 Apr 2005, 20:07
Location: Next to the girl with kaleidascope eyes
Other than 'not having to deal with Upspring'?
Top
 Offline Profile  
 
PostPosted: 29 Mar 2010, 15:57 
Moderator
User avatar

Joined: 06 Aug 2005, 12:15
Well other than not having a newer .s3o exporter for 3dmax and not being able to get models exported..

I still like having upspring though, it gives a pretty decent preview of the model for doing quick fixes with a .s3o ect...

Having the objects being reversed on x is a pain sure, but having something that can show you near 100% of how the model looks and functions and be the last step before importing into a mod, its a pretty handy tool.

You still need Upspring for setting up the bounding sphere and height anyway though right?

Guess it all comes down to preference, and which format is more work in the end and what benefits it can have between them.
Top
 Offline Profile  
 
PostPosted: 29 Mar 2010, 16:10 
Spring Developer

Joined: 08 Oct 2006, 15:58
SpliFF wrote:
Have you written an s3o converter already?


Yes.

MR.D wrote:
Whats the advantage of using .obj instead of .s3o?


That's up to artists to decide for themselves, I don't do sales-pitches.

MR.D wrote:
You still need Upspring for setting up the bounding sphere and height anyway though right?


Nope, all relevant metadata for OBJ's comes from the Lua scripts.
Top
 Offline Profile  
 
PostPosted: 29 Mar 2010, 20:25 
MC: Legacy & Spring 1944 Developer
User avatar

Joined: 29 Apr 2005, 00:14
Location: #moddev - join it!
Quote:
For the time being, OBJ's get rendered in (almost) exactly the same way that S3O's are, so they must have a primary and secondary texture. This may change in the future if the format is picked up.


Can't help but feel maybe there is a chicken and the egg situation here; I doubt it'll get picked up in a major way unless it offers things that s3o does not (materials, multiple diffuse textures per model, etc)

Still, awesome work. :-)
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 01:45 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
FLOZi wrote:
I doubt it'll get picked up in a major way unless it offers things that s3o does not (materials, multiple diffuse textures per model, etc)


It does offer one thing: you can modify your unit in your 3D editor without also having to re-convert it via UpSpring. You're only going to have to regenerate metadata if you alter your piece hierarchy, offsets, or overall unit dimensions. If you're just adding flair or remodelling existing parts there's an excellent chance you can export straight from your editor to Spring without an intervening step.
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 13:22 
Modeler
User avatar

Joined: 28 Apr 2005, 20:07
Location: Next to the girl with kaleidascope eyes
Well, I know I'll be using it. Just out of curiosity, in the core_commander.obj.lua, what is the core_commander_alt section for?

And from the looks of things, for those who can't figure out / don't know how to apply two textures to one material, you can just edit the txt file. In fact, you'd probably have to do it anyway, to add the 'null' pieces which I don't think wings supports:

Code:
# name: objects3d/core_commander.s3o
# texture0: core_commander_1.dds
# texture1: core_commander_2.dds

o pelvis
# name: pelvis, number: 1
# triangles: count = 462
# global   offset: -0 34 -0
# relative offset: 0 34 0

(A very big block of co-ordinates)

o orbit
# name: orbit, number: 18
# quads: count = 0
# global   offset: -0 0 0
# relative offset: 0 34 0


o orbitfire
# name: orbitfire, number: 19
# quads: count = 0
# global   offset: -0 0 0
# relative offset: 0 34 0


o landpoint
# name: landpoint, number: 20
# quads: count = 0
# global   offset: -0 -35 0
# relative offset: 0 -1 0


I'd like to know the difference between relative and global offset, other than that, it seems to be self-explanatory. I'm assuming from the "# name: objects3d/core_commander.s3o" line that they're referred to in units/ files same as real .s3os? ie "objectName = [[atreides.s3o]]," would be valid for both obj and s3o formats?
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 13:46 
Spring Developer

Joined: 08 Oct 2006, 15:58
FLOZi wrote:
Can't help but feel maybe there is a chicken and the egg situation here; I doubt it'll get picked up in a major way unless it offers things that s3o does not (materials, multiple diffuse textures per model, etc)


Maybe, but I don't know the consensus (if there is one) on what people find lacking about S3O. Multiple diffuse textures per model sharing the same UV space (or even per-piece textures) wouldn't be that hard to support for example, but there would still have to be a commonly accepted way of deciding when to bind and unbind them. And it's also already possible with Lua gadgetry, which is the more powerful approach in the end.

Guessmyname wrote:
what is the core_commander_alt section for?


To demonstrate you can specify the piece hierarchy in two ways, eg.

Code:
   pieces = {
      pelvis = {
         ...
      }
   }


versus

Code:
   pieces = {
      [1] = {
         name = "pelvis",
         ...
      }
   }


The second ("alt") approach preserves the lexicographical ordering among child pieces, which might be important for converted S3O's.

Guessmyname wrote:
I'd like to know the difference between relative and global offset


A relative offset is defined with respect to the immediate parent piece, global offsets are defined with respect to the root. But actually the comments in the .obj are reversed, all global offsets should be relative and vice versa. :-)

Guessmyname wrote:
I'm assuming from the "# name: objects3d/core_commander.s3o" line that they're referred to in units/ files same as real .s3os? ie "objectName = [[atreides.s3o]]," would be valid for both obj and s3o formats?


No, that comment (all lines starting with '#' are comments) is just there to indicate the name of the source S3O. For an OBJ model, you would write:

Code:
objectName = [[atreides.obj]],
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 14:14 
Modeler
User avatar

Joined: 28 Apr 2005, 20:07
Location: Next to the girl with kaleidascope eyes
Ah, okay. Thanks!

And yeah, main lacking in s3o is the 'one UV set per unit' limit. Can't see there being much else in terms of advantage/disadvantage between the two (apart - again - from the ease of export using obj)
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 15:51 
Cursed Zero-K Developer
User avatar

Joined: 07 Nov 2007, 21:48
Location: Horse
Is there an app where I can edit an obj, then set positions and origins of individual pieces, which can then be used to generate the lua partner file? If not, how can I possibly avoid Upspring?
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 17:30 
Spring Developer

Joined: 08 Oct 2006, 15:58
CarRepairer wrote:
Is there an app where I can edit an obj, then set positions and origins of individual pieces, which can then be used to generate the lua partner file?


No, the information contained in standard .obj's is not enough to generate the companion scripts from. The piece-tree structure could maybe be inferred by an external application by introducing special "link" objects to your model (eg. an object A_B to make B a child of A), but not the offsets.

This problem applies to many other common model formats that I know of as well.

Quote:
If not, how can I possibly avoid Upspring?


At present, the only other way would be by writing/updating it manually while you create the model. For editors like Blender a plugin might also be able to take care of some of the work.

Edit: this indeed looks to be the case, I'll hack one together for y'all.
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 18:09 
User avatar

Joined: 21 Feb 2005, 03:38
Location: Herding cats uphill whilst wearing roller skates.
Can we have a variant of this that will input OBJ data and output a display list? Please?
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 18:13 
Cursed Zero-K Developer
User avatar

Joined: 07 Nov 2007, 21:48
Location: Horse
Kloot wrote:
No, the information contained in standard .obj's is not enough to generate the companion scripts from. The piece-tree structure could maybe be inferred by an external application by introducing special "link" objects to your model (eg. an object A_B to make B a child of A), but not the offsets.

Wait, you missed my point. The piece-tree structure is the least of my worries. I can easily type some piece names like body={ head, arm={hand}, leg1, leg2}... In fact that's a bonus because I don't have to re-make the tree each time like when I edit a file in blender/wings then import to Upspring. I can hang onto that file.

It's this part that scares me:
Code:
offset = {7.7157217504009e-08, 2.4599997997284, 0.72614061832428},
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 18:24 
Cursed Zero-K Developer
User avatar

Joined: 07 Nov 2007, 21:48
Location: Horse
Maybe I'm thinking of this the wrong way. Upspring isn't bad, it's just the hassle when you need to edit an obj (or whatever), then re-importing it into Upspring causes loss of work because the hierarchy and offsets are gone. Not to mention the uproar of ruined normals (not even something I myself am concerned with). If Upspring itself had a tool to create the hierarchy with offsets based on a simple lua file that contained piecename hierarchy but not offsets (since I can type this manually), then the problem could be solved. Each time you'd edit the obj in wings, import in Upspring, run the tool and you're set. This was really my only concern - "oops I need to change one polygon in the model source. Now I have to edit it, then load it in Upspring and set up the hierarchy all over again."
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 19:49 
Modeler
User avatar

Joined: 28 Apr 2005, 20:07
Location: Next to the girl with kaleidascope eyes
CarRepairer wrote:
Kloot wrote:
No, the information contained in standard .obj's is not enough to generate the companion scripts from. The piece-tree structure could maybe be inferred by an external application by introducing special "link" objects to your model (eg. an object A_B to make B a child of A), but not the offsets.

Wait, you missed my point. The piece-tree structure is the least of my worries. I can easily type some piece names like body={ head, arm={hand}, leg1, leg2}... In fact that's a bonus because I don't have to re-make the tree each time like when I edit a file in blender/wings then import to Upspring. I can hang onto that file.

It's this part that scares me:
Code:
offset = {7.7157217504009e-08, 2.4599997997284, 0.72614061832428},


Copy it out from within Wings.
Top
 Offline Profile  
 
PostPosted: 30 Mar 2010, 20:02 
User avatar

Joined: 21 Feb 2005, 03:38
Location: Herding cats uphill whilst wearing roller skates.
One at a time? For every Piece? And if you need to make adjustments later?
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 121 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.