obj vs 3ds when importing into upspring

[Saktoth]

In the 'New Spring model system' thread, several people have expressed the opinion that obj is a better format to import into upspring than 3ds.

However, obj imports as a single object, meaning you must import every piece of the model separately and load them in one at a time.

How else? 3ds imports as an incorrectly rotated solid lump as well.

I dont know what modelling program you are using but from wings, upspring imports the pieces from 3ds just fine.

it's just 10 more minutes and the good feeling that you're doing it the right way

Smoth and Flozi both agree with this. I dont understand: The Right Way? Is obj superior in some way to 3ds?

[trepan]

I suggest that you download the specifications for both
file formats, and read them (at least twice). Maybe then
you'll be less likely to post bullshit (unless you're talking
about the manner that a specific implementation loads
models, in which case that should be specified).

[Das Bruce]

Seperate objects in an OBJ file are defined, it's the loader ignoring them that causes it to be loaded as a solid lump.

/edit/Here's an obj containing two cubes exported from wings, there's no hierarchy defined in the file exported from and I don't have wings here to create one but this clearly shows two objects "o cube1" and "o cube1_copy2".

Code: Select all

# Exported from Wings 3D 1.2.rc3
mtllib test.mtl
o cube1_copy2
#8 vertices, 12 faces
v 0.67566643 -1.00000000 1.00000000
v 0.67566643 1.00000000 1.00000000
v 2.67566643 1.00000000 1.00000000
v 2.67566643 -1.00000000 1.00000000
v 0.67566643 -1.00000000 -1.00000000
v 0.67566643 1.00000000 -1.00000000
v 2.67566643 1.00000000 -1.00000000
v 2.67566643 -1.00000000 -1.00000000
vn -0.57735027 -0.57735027 0.57735027
vn -0.57735027 0.57735027 0.57735027
vn 0.57735027 0.57735027 0.57735027
vn 0.57735027 -0.57735027 0.57735027
vn -0.57735027 -0.57735027 -0.57735027
vn -0.57735027 0.57735027 -0.57735027
vn 0.57735027 0.57735027 -0.57735027
vn 0.57735027 -0.57735027 -0.57735027
g cube1_copy2_default
usemtl default
s 1
f 1//1 4//4 2//2
f 1//1 5//5 4//4
f 2//2 4//4 3//3
f 2//2 5//5 1//1
f 2//2 7//7 6//6
f 3//3 7//7 2//2
f 4//4 5//5 8//8
f 4//4 7//7 3//3
f 5//5 7//7 8//8
f 6//6 5//5 2//2
f 6//6 7//7 5//5
f 8//8 7//7 4//4
o cube1
#6 vertices, 8 faces
v -2.45629901 -1.00000000 1.00000000
v -0.45629901 1.00000000 1.00000000
v -0.45629901 -1.00000000 1.00000000
v -2.45629901 -1.00000000 -1.00000000
v -2.45629901 1.00000000 -1.00000000
v -0.45629901 -1.00000000 -1.00000000
vn -0.69474659 -0.18615679 0.69474659
vn 0.54772256 0.63245553 0.54772256
vn 0.40824829 -0.81649658 0.40824829
vn -0.40824829 -0.81649658 -0.40824829
vn -0.54772256 0.63245553 -0.54772256
vn 0.69474659 -0.18615679 -0.69474659
g cube1_default
usemtl default
s 1
f 9//9 10//10 13//13
f 9//9 12//12 11//11
f 9//9 13//13 12//12
f 10//10 14//14 13//13
f 11//11 10//10 9//9
f 11//11 12//12 14//14
f 11//11 14//14 10//10
f 13//13 14//14 12//12

[Hoi]

However, obj imports as a single object, meaning you must import every piece of the model separately and load them in one at a time

You can have multiple pieces with obj, but that retarded program called upspring doesn't recognize the pieces and sees the entire model as one piece.

[jK]

having multiple pieces != hierarchy

[Hoi]

But why would you want to set hierarchy in your modeling program?

[FLOZi]

having multiple pieces != hierarchy

Did someone suggest otherwise?

Ideally Upspring would import multi-object OBJ with each piece being on the same level of hierarchy (either all in the root or if that isn't possible have an empty root object and all pieces as childs of that), easy enough for the user to then move things around as they should be, even with Upspring as it is now.

[rattle]

I don't export as 3ds because it seems that wings' 3ds exporter unwelds vertices where seams are resulting in messy hard edges all over the place.

But why would you want to set hierarchy in your modeling program?

Why not? It'd be nice to have this in wings as well as true origins, not these halfassed on the fly origins that I'm using.

You could use 3ds max and it's broken s3o exporter of course...

[smoth]

this thread is delicious. I esp like the really bad starting post filled with assumptions about format.

They are telling you the correct information sak.

[SpliFF]

According to the OBJ specification, OBJ supports groups, but not hierarchy.

According to lib3ds, which should know, 3DS models have hierarchy. According to UpSpring however it does not. That's simply incorrect. Perhaps it's a legacy of lib3ds or UpSpring implementations.

You create hierarchies in 3DS Max using the "link" tool.

As far as the proposed loader goes, it's largely irrelevant. Your hierarchy will be converted to Lua which means you only have an issue when re-editing in a 3D tool (because no 3D packages support additional Lua metadata). The issue isn't that important as long as you name any new pieces and update your Lua (via Upspring or by hand).

Most modern 3D formats DO support hierarchy, so if you use 3DS or upgrade to Collada or other formats then your hierarchy will be preserved without the need for Lua.

However, should you remap your pieces via Lua then Spring will always obey the Lua, allowing you to remap any model regardless of whether it has hierarchy internally or not.

Most of peoples misunderstandings on this topic are based on UpSpring - and Upsring is simply wrong about 3DS and wrong about how it loads certain objects. I'm working on that problem right now.

It is not essential for UpSpring to read your model. That's just a courtesy to people who want a GUI for setting piece hierarchy (for OBJ only) and radius/height.

Maybe one day someone will plug assimp into UpSpring this will allow direct Lua generation for every format Spring supports. For now 3DS/OBJ is sufficient as a common format because most tools can write one or both of these.

Upspring supports 2 additional formats other than S3O/3DO. One is called Object Package (OPK), the other is called Common 3D MdlObject (C3O). I've yet to see a tool that supports either or even find any information. I think it's pretty safe to call these formats legacy and irrelevant.

But why would you want to set hierarchy in your modeling program?

Why wouldn't you? Do you have a hard-on for UpSpring?

[Saktoth]

In the 'New Spring model system' thread, several people have expressed the opinion that obj is a better format to import into upspring than 3ds.

Not spring, Upspring. This isnt about the future model importer, or what obj is capable of, its about how Upspring loads it. Thats is why i started this new thread, this is in regards to this:

Pretty sure OBJ, which is probably by far the most common format used within the Spring Community for exports, is non-hierarchical.

You use obj? I used 3ds, my obj tends to import as a solid lump rather than its seperate parts. Always thought 3ds was the standard for that reason.

OBJ actually supports multiple pieces, but upspring (and some other progs, too) doesn't know about it and always reads/writes obj as one piece. Not sure if it has hierarchy though or just multiple pieces at the same level (like 3ds export from upspring for ex.)

Is yuritch wrong here? That 3ds imports into upspring with seperate pieces intact, but obj does not? Thats been my observation too. Is there some way to import obj into upspring that doesnt fuse the object that i am not aware of? Is there some reason that makes obj superior to 3ds that makes up for the difficulty of having to import each piece separately? I ask this with full sincerity and humility: I wish to know why obj would be the standard (as FLOZi says) given how upspring handles it, so that if there is some terribly good reason, i can switch.

You can see yuritch has already cleared up the fact that obj does support multiple pieces and as far as the new importer goes, is fine. Thats not what this is about.

[Hoi]

I don't export as 3ds because it seems that wings' 3ds exporter unwelds vertices where seams are resulting in messy hard edges all over the place.

I'm not sure but I think latest dev version fixed this.

[Master-Athmos]

Is there some reason that makes obj superior to 3ds that makes up for the difficulty of having to import each piece separately? I ask this with full sincerity and humility: I wish to know why obj would be the standard (as FLOZi says) given how upspring handles it, so that if there is some terribly good reason, i can switch.

Well the bottom line is this: 3ds is a totally outdated and format and was abandoned many many years ago. The reason were its limitations:

IIRC it only can have 8 char names and can only store 65536 vetices. For Spring that might not be THAT important but as a general format those limitations made it die years ago. I did have some bad experiences with 3ds in Spring too though as something about the exported 3ds wasn't imported right with Upspring - no idea what it was though...

Nowadays you also might want to store more stuff like bones information, light positions and stuff like that needing a new format. Currently .fbx files are pretty popular in games. While .obj files cannot store that much game relevant information they still have one big advantage - they're an excellent format for simply ex- and importing geometry as it stores all the information you might want on that sector and you have next to no hassle with im- and exporters interpreting certain things in a different way which can become a problem for formats like .fbx where you might get junk when using two pieces of software based around a slightly different version of .fbx...

So you might have a point that for Upspring 3ds isn't that bad. As I've encountered some problems with that format (not just when trying to get it into Spring but also between different 3d software) I also tend not to use it but rather go for the .obj format which is just great for such simple geometry exports. With either a batch importer or a support for the multiple pieces in the first place the very little time advantage 3ds has would disappear so it probably would be a good idea to give this some attention...

[Saktoth]

With either a batch importer or a support for the multiple pieces in the first place the very little time advantage 3ds has would disappear so it probably would be a good idea to give this some attention...

Well yes certainly, but there is going to be a whole new model importing system re Spliff's thread, but this isnt about that.

I'd love if you could remember what these problems you've had with upspring and 3ds are (or smoth, or someone else, could tell me). Regardless of the limitations of 3ds, the final format is .s3o anyway.

Rattle said unwelding vertices but i've never noticed this, and Hoi says its been fixed.

Im really not trying to make a statement over which method should be used here, especially not for the future model importer, i am trying to understand if there is some huge collosal problem with all the models i have imported as .3ds into upspring (like unwelded vertices or something equally catastrophic).

[FLOZi]

It's mainly a case of personal taste, Sak.

And yes, with obj you have to export/import each object separately.

I'm afraid I can't really remember the problems i ran into with 3ds either - I find rigging models in Upspring to be so tedious i made Spiked do all of the S44 models himself.

[Master-Athmos]

Im really not trying to make a statement over which method should be used here, especially not for the future model importer, i am trying to understand if there is some huge collosal problem with all the models i have imported as .3ds into upspring (like unwelded vertices or something equally catastrophic).

Not just because you used the 3ds format. There of course can be some problems with the 3ds exporters of certain softwares - especially as nobody really cares about it anymore and invests lots of time for a fix. Seems like Wings had some and afaik some standalone modellers don't save any information about the hierarchy (as today there's more to it than just the hierarchy and also quite a bit depending on which software suite you use for scene layout, animation & rendering) but there shouldn't be any major general flaws created by the 3ds format itself...

So in the end just keep using it if you're comfortable with that. For the world beyond Spring I wouldn't do that though and I also wouldn't tell newbies to do it that way. Apart from that using .obj isn't as time consuming as someone said with like 10 minutes. Importing is a piece of cake and partially it's the time you invested in your software to create the hierarchy you now spend in Upspring. You have your folder with all the seperate objects and just create new empty items in Upspring you replace with your .objs and that's that. So what remains is just the export of your pieces into seperate files. While this of course takes more time for more complex models I wouldn't really call it "time consuming" and maybe there even is a batch save function in your software which does that job for you...

[SpliFF]

Not directly relevant to this particular debate (3ds vs Obj), but I see Collada becoming the leading standard right across the board. Looking at the supported software list there's an impressive amount of support coming online with many tools now supporting it as a "first-class format" (meaning, not handled via third-party plugin). The latest in this list being Google SketchUp.

List of tools supporting Collada

Significantly among the list is Wings, Blender, 3DS Max, Lightwave and Maya which pretty much covers the tools the Spring community depends on (unless you count Argh and his love for "Rhino", whatever that is).

Being a royalty-free format also makes it ideal for free / open-source assets which is why many galleries are starting to appear using Collada as preferred format and why many open-source games, engines and libraries are adding first-class support.

Finally, it's probably the most feature-packed format in existence, with physics data now integrated into the format. It also presumably supports application-specific data like SVG does.

So what this means is that adding Collada support to Spring and UpSpring would make OBJ vs. 3DS an irrelevant issue. I only brought this up because I think that BOTH OBJ and 3DS are obsolete. Anyway, I realise this thread isn't talking about the future and no support exists in Spring/UpSpring for Collada yet so don't let me derail this thread.

[FLOZi]

Actually both myself and Warlord_Zsinj use Rhino too, but we're old skool TA modellers.

[smoth]

fucking children these days.

here saktoth.

click image for larger

if you cannot tell what is wrong with the model on the right... you have a penis for a tongue.

[Argh]

I've never had that problem with exports from Rhino, Smoth, but I can see what you're saying there.

Newest dev build of Wings, advanced options on export. Dunno if that will help or not, there you go.