ANN: OBJ model format support

ANN: OBJ model format support

Share and discuss visual creations and creation practices like texturing, modelling and musing on the meaning of life.

Moderators: MR.D, Moderators

Post Reply
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

ANN: OBJ model format support

Post by Kloot »

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:
core_commander.obj.lua
(4.29 KiB) Downloaded 326 times
core_commander.obj.txt
(488.61 KiB) Downloaded 370 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:
SpringOBJMetaDataScriptExporter.py.txt
(9.77 KiB) Downloaded 283 times
Last edited by Kloot on 05 Sep 2012, 11:54, edited 11 times in total.
User avatar
Das Bruce
Posts: 3544
Joined: 23 Nov 2005, 06:16

Re: ANN: OBJ model format support

Post by Das Bruce »

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?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

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).
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: ANN: OBJ model format support

Post by SpliFF »

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?
User avatar
MR.D
Posts: 1527
Joined: 06 Aug 2005, 13:15

Re: ANN: OBJ model format support

Post by MR.D »

Whats the advantage of using .obj instead of .s3o?
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: ANN: OBJ model format support

Post by Guessmyname »

Other than 'not having to deal with Upspring'?
User avatar
MR.D
Posts: 1527
Joined: 06 Aug 2005, 13:15

Re: ANN: OBJ model format support

Post by MR.D »

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.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

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.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: ANN: OBJ model format support

Post by FLOZi »

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. :-)
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: ANN: OBJ model format support

Post by SpliFF »

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.
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: ANN: OBJ model format support

Post by Guessmyname »

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: Select all

# 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?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

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: Select all

	pieces = {
		pelvis = {
			...
		}
	}
versus

Code: Select all

	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: Select all

objectName = [[atreides.obj]],
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: ANN: OBJ model format support

Post by Guessmyname »

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)
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

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?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

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.
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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: ANN: OBJ model format support

Post by Argh »

Can we have a variant of this that will input OBJ data and output a display list? Please?
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

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: Select all

offset = {7.7157217504009e-08, 2.4599997997284, 0.72614061832428},
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

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."
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: ANN: OBJ model format support

Post by Guessmyname »

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: Select all

offset = {7.7157217504009e-08, 2.4599997997284, 0.72614061832428},
Copy it out from within Wings.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: ANN: OBJ model format support

Post by Argh »

One at a time? For every Piece? And if you need to make adjustments later?
Post Reply

Return to “Art & Modelling”