Integrating alternate model formats - Page 7

Integrating alternate model formats

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
Erik
Posts: 283
Joined: 20 Aug 2009, 20:49

Re: Integrating alternate model formats

Post by Erik »

Works fine aside from the maps missing their textures.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Integrating alternate model formats

Post by abma »

assimp is avaiable at github: https://github.com/assimp/assimp/wiki

so a submodule would be possible...
User avatar
KaiserJ
Community Representative
Posts: 3113
Joined: 08 Sep 2008, 22:59

Re: Integrating alternate model formats

Post by KaiserJ »

i for one am greatly looking forward to assimp inclusion in the next main (unless i missed something and it's already in)
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Integrating alternate model formats

Post by FLOZi »

We should probably try and aim for a preferred format imo for the likes of tutorials and whatever. Iirc Spliff favours collada?
User avatar
MidKnight
Posts: 2652
Joined: 10 Sep 2008, 03:11

Re: Integrating alternate model formats

Post by MidKnight »

FLOZi wrote:We should probably try and aim for a preferred format imo for the likes of tutorials and whatever. Iirc Spliff favours collada?
Agreed.

What makes one format better than another? If someone could do a pro/cons spot for the formats in question, I'd be much obliged.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Integrating alternate model formats

Post by AF »

Collada is intended as a format for transferring between different tools, it's more likely to hold all data, but it's not optimised for game engines ( though once loaded by ASSIMP it wont make a difference anyway, so all arguements go out the window )
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Integrating alternate model formats

Post by jK »

The parsing of a xml file just takes a wink or do you argument that html should be dropped for a binary fileformat?
Not to forget that the decompression of the texture + uploading to the VRAM takes 10k-10Mx more time.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Integrating alternate model formats

Post by AF »

No I was just making the point that the obvious collada counter arguements are all nullified by ASSIMP
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Integrating alternate model formats

Post by SpliFF »

Big News

ASSIMP support is about to get its first real release in 83.0. Thanks to everyone who made this possible (spring devs and testers). Special thanks to Kloot, BrainDamage and jK who worked on importer and abma and hoijui who assisted with some merge complications. Also CarRepairer for being the first to test.

I'll need time to put together a proper howto / wiki page for this but in the meantime I'll dump some notes in this thread. Be aware that anything said in this thread is subject to change due to ASSIMP bugfixes. It may be released but that doesn't make it stable or well tested. Once a wiki page goes up the information in this thread should be considered obsolete.

To start things off here's an extract from a chat with CarRepairer that may be of help to blender users. It covers
  • Telling Spring how to find your ASSIMP model
  • Spring doesn't use embedded textures in models (yet)
  • No support for multiple textures in models (yet)
  • Teamcolor and missing textures (your model is all red / teamcolor backwards)
  • Textures should be named after unit (model?) unless set via metafile
  • Teamcolor channel on tex1 is backwards relative to S3O (and why)
  • Using S3O behaviour for teamcolor is a metafile option
  • Enabling texture and Model logging to infolog.txt
  • Model metafiles are optional, height can be auto-detected
  • Kloot OBJ support still in engine, used for OBJ files
  • Model facing the wrong way
  • Building parent-child relationships in Blender 2.5+
  • Global versus local (parent / inverse) coordinates in Blender
  • Telling Spring to use relative positioning for a child
  • Meshes versus objects/nodes and relationship to Spring "pieces"
  • Applying transforms to a node
  • Origins and rotations
  • Model/Piece scaling support in engine (current situation and possibilities)
http://www.warriorhut.org/spring/docume ... p_chat.txt
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Integrating alternate model formats

Post by AF »

Congratulations SpliFF
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: Integrating alternate model formats

Post by Neddie »

This is very good news, I can't wait to see the result.
User avatar
Rafal99
Posts: 162
Joined: 14 Jan 2006, 04:09

Re: Integrating alternate model formats

Post by Rafal99 »

I am just trying to use the Assimp loader to get models into Spring and run into a lot of problems. There is no reliable format to easily transfer the model from Wings3D to Spring. Collada would be ok but Wings3D adds suffixes to the object names when exporting. Blender does same thing but with another suffix.
Wavefront Obj is a pain to make Spring load it. You need to remove manually from the obj file all the tags Spring doesn't recognize or it won't load...
Other formats either doesn't save normals or UV coords or the exporter is bugged...

Edit:
Nevermind, I figured how to revent original piece names by doing a few search-and-replace queries in the .dae file. But it wasn't obvious since Wings3D exporter adds "-0" to the piece names and you can't just search for "-0" because it also occurs in vertex coordinates like "-0.2" for example.

Now for some reason Spring doesn't read my .lua metafile supplied with model but also doesn't print any errors...

Edit2:
Changing .lua to .dae.lua made it work, but still it only reads the texture name from it. Piece hierarchy seems to get ignored. I even enabled all the model related log subsystems but the only thing they print is texture being loaded...

Edit3:
After some investigation it seems that only Texture log subsystem got enabled. Others (Model,Model-detail,Piece,Piece-detail) don't appear in the "Available log sections" nor in "Enabled log sections"...
So I am stuck now...
Last edited by Rafal99 on 29 Dec 2011, 10:42, edited 1 time in total.
User avatar
Rafal99
Posts: 162
Joined: 14 Jan 2006, 04:09

Re: Integrating alternate model formats

Post by Rafal99 »

Ok it all doesn't work as I expected. :?
The assimp lua metadata file was said to be compatible with the Kloot's obj loader metadata, but clearly is not.
In obj metadata you could do:

Code: Select all

pieces = {
   chassis = {
        turret = {
            barrel = {},
        },
   },
}
But it doesn't work with assimp!
What works is:

Code: Select all

pieces = {
   chassis = {},
   turret = {
      parent = "chassis",
   },
   barrel = {
      parent = "turret",
   },
}
I have seen this new field "parent" in the examples but also expected the old syntax to work too since they are "compatible" but meh...
Well this syntax is clearly an disadvantage but I can lua it to convert between each other, it is not the biggest problem.

The biggest problem is:
Spring ignores in the metafile pieces that doesn't exist in the model!
How am I going to add all the empty pieces for the hierarchy and for firepoints, emit-sfx-points etc? Seriously wtf!?

Yeah obj parser requires the empty pieces to be put into the model too, but with .obj file it is not a problem to add the needed lines. But with .dae it would be challenge in itself...

Unfortunately I have to stick to the .obj for now. :/
The unforeseen issues, the lack of a good documentation and the lack of any output from the engine about errors in the metafile make it too hard to work with...
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Integrating alternate model formats

Post by CarRepairer »

Two things I recommend. First, learn blender. You won't need a metafile for hierarchy and origins. Second, for "empty pieces" I add a simple plane (single polygon) and hide it in the script.
User avatar
Rafal99
Posts: 162
Joined: 14 Jan 2006, 04:09

Re: Integrating alternate model formats

Post by Rafal99 »

The point is I prefer to set the hierarchy and origins in a text file, where I can just type the proper numbers, rather than having to set them by moving pieces and have the UI get in my way. Otherwise I would be using Upspring...
As for adding non-empty pieces and hiding them later ... I bet it would generate a whole new amount of problems, since empty pieces are treated in a little different way in Spring.

For now I will stick to .obj
The drawbacks are:
- I have to clear every .obj file from tags Spring doesn't like, or it will spam me to hell in the infolog. Probably going to make an app to do this.
- I have to add empty pieces at the end of obj file. The syntax is just "o piecename" so much less trouble than your solution.
- I have to flip textures manually since the new textureflipping tags weren't backported to the obj loader.

Still better than dealing with Upspring.
Hopefully Spliff can do something with the "empty pieces must be in the model" requirement because it is a serious drawback.
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Integrating alternate model formats

Post by CarRepairer »

Setup hierarchy:

Blender:
Rightclick child piece
Rightclick parent piece
Ctrl+p, enter.

Metafile
Type out a table like
parentpiece = { childpiece = ....
Editing this can't be fun.

Adding empty pieces:
Blender:
Do this once and never again:
Add > Plane
In the LUS hide(piecename)

Metafile:
Every time you export your obj after editing your model:
You have to copy/paste your "o piecename" each time.

How is the blender way even hard at all? The only thing hard here is learning blender in the first place 8)
User avatar
Rafal99
Posts: 162
Joined: 14 Jan 2006, 04:09

Re: Integrating alternate model formats

Post by Rafal99 »

But I would have to do it every time I modify my model and export it from Wings, so it is exactly like Upspring which I hate.
While the metadata file I just write once and it is done, also I like typing code :)
Anyway making a metafile with hierarchy is not a problem at all for me, I was just annoyed at first because I spent several hours trying to get the model to work only to discover the old syntax doesn't work with assimp.

As for empty pieces. Hidden piece != empty piece.
Empty pieces are optimized in Spring, while non-empty pieces may be performance intensive and my models already have a LOT pieces since they are ships with a lot of bigger and smaller guns. There were also some differences regarding per-piece collision volumes which I don't even really remember now.
Adding extra planes to the model is an (literally) ugly workaround and won't be able sleep easily doing this to my models! :P

Btw learning Blender? I would rather write a patch to fix Spring, will be less effort...
Well, I would have to deal with mingw32 so maybe not really...
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Integrating alternate model formats

Post by CarRepairer »

Rafal99 wrote:But I would have to do it every time I modify my model and export it from Wings
Well okay if you disregard the part where I said
CarRepairer wrote:First, learn blender.
then of course.

I like coding too but there's no way that typing out your hierarchy is less work than using a gui to set it up.
Rafal99 wrote:Btw learning Blender? I would rather write a patch to fix Spring, will be less effort...
I mean this in the most optimistic encouraging way: I learned blender and I am not a modeler. Once I learned how to use it, I found it much more pleasant to use than wings3d. I wish you luck.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Integrating alternate model formats

Post by hoijui »

sorry rafal, the missing log sections to enable are my fault, it is fixed here:
https://github.com/spring/spring/commit ... f75c281886

you can try with a buildbot version of spring from branch develop after this commit, to get more info.
as we now have different logging levels, the *-detail sections do not exist anymore (they are not L_DEBUG log levels of the normal sections).
to enable even these messages, you will need a DEBUG build of the engine though, as they are not compiled in in the normal version, and can therefore not be enabled (if i remember right).
User avatar
Rafal99
Posts: 162
Joined: 14 Jan 2006, 04:09

Re: Integrating alternate model formats

Post by Rafal99 »

Yay I helped to find a bug! :D
Thanks for a quick fix Hoijui. I will get the latest build from buildbot.

Edit: I see there is no debug build available for download. Tried the one ending with _spring_dbg but it seems to be debug symbols or something.
I got the normal build then, will try to compile the debug one later.


By the way I am thinking of making a simple ingame lua version of upspring - just a gadget/widget to visually make piece hierachy and set the offsets and then output it to a lua metafile. There seems to be a need for such utility.
I have tried the unit drawing functions like gl.UnitPiece and they work like expected so the whole thing shouldn't be too troublesome. Will check the Unit Poser code too.

Still it would be necessary to allow empty pieces to be defined in the metafile not in model so Spring code needs to be modified. I may get to this too.
But obviously I can't promise anything until I make some progress.


@CarRepairer:
Thanks for your input. I may learn the Blender eventually since its interface is much less scary these days, but in this situation it would kinda be a workaround, and I prefer to fix the issue itself, even if it requires more work, at least others will have more options than just Blender or Upspring.
Post Reply

Return to “Engine”