View topic - Integrating alternate model formats


All times are UTC + 1 hour


Post new topic Reply to topic  [ 140 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
PostPosted: 02 Dec 2010, 05:14 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
the collision stuff isn't fully implemented yet but there's no reason it shouldn't be able to. i think the sensible approach would be to treat usePieceCollisionVolumes exactly as it is now (adds a box volume to each piece) but then allow overriding individual volume properties in the metafile. I'd need to have another look at the collision code to be sure.
Top
 Offline Profile  
 
PostPosted: 02 Dec 2010, 14:20 
MC: Legacy & Spring 1944 Developer
User avatar

Joined: 29 Apr 2005, 00:14
Location: #moddev - join it!
SpliFF wrote:
the collision stuff isn't fully implemented yet but there's no reason it shouldn't be able to. i think the sensible approach would be to treat usePieceCollisionVolumes exactly as it is now (adds a box volume to each piece) but then allow overriding individual volume properties in the metafile. I'd need to have another look at the collision code to be sure.


Yeah, sounds like what I envisioned would be the best solution.
Top
 Offline Profile  
 
PostPosted: 02 Dec 2010, 22:22 
Spring Developer
User avatar

Joined: 28 Jun 2007, 06:30
SpliFF wrote:
I've done a lot work to support transforms of objects. Until now you had to "apply" your scale/rotation/offsets in your editor (which changes the actual mesh data). With the new system the transforms are passed directly through to Open GL and COB/Lua. This has been complicated in part because COB never had piece scaling support (only rotation and offsets).

Please remove the scaling support. It makes math quite (/extreme) complex. It's quite unlikely that a new model rendering shader system will support this (dropping scaling can give a HUGE performance increase).

Oh and instead of disabling the modelcache, you should add the ability to reload a model in the cache. As it was done with /reloadcob.

Except that good work.
Top
 Offline Profile  
 
PostPosted: 03 Dec 2010, 06:00 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
I'd like to reserve my judgement on the scaling issue until I've seen more evidence of the problems you refer to. Right now scaling (at least from a visual sense) is working fine and I'd have to do more testing to be sure of the effects on Lua/COB. But really, scaling a matrix is not particularly expensive, the whole function is:

Code:
void CMatrix44f::Scale(float scalex, float scaley, float scalez)
{
  m[0] *= scalex;
  m[1] *= scalex;
  m[2] *= scalex;
  m[3] *= scalex;

  m[4] *= scaley;
  m[5] *= scaley;
  m[6] *= scaley;
  m[7] *= scaley;

  m[8] *= scalez;
  m[9] *= scalez;
  m[10] *= scalez;
  m[11] *= scalez;
}


And the entirety of the rendering changes is basically:
Code:
if (scale.x!=1.0f || scale.y!=1.0f || scale.z!=1.0f) { glScalef(scale.x, scale.y, scale.z); }


I just don't see these changes being expensive or complex and I don't see how glScalef is going to break a shader since it's presumably already being used in numerous camera-related transformations.

On the other hand the pros of scaling support are pretty good. For a start it lets you reuse assets which aren't scaled correctly for spring (which is pretty much every model that hasn't been resized through UpSpring). For seconds it's a prerequisite of using any imported animation track since animation points normally include position, rotation and scale.

I realise there are a couple of matrix operations in Spring that currently assume no scaling but they can be fixed. In fact 90% of the CMatrix44f class could be replaced with Assimps' aiMatrix4x4 class which also supports scaling and quaternion rotations. It only lacks a few Spring-specific methods like setting the "Up" vector.

A big con of having no scaling support is that it breaks support for proper relative transforms as provided by most model formats. The artist has to keep applying their transforms which adds an extra step to the export/save workflow and quite possibly affects other things like animations and such..
Top
 Offline Profile  
 
PostPosted: 03 Dec 2010, 17:53 

Joined: 27 Jun 2009, 00:32
Location: Germany
Would it be possible to have a dynamic scaling for pieces (i.e. for animation in the unit script)? It would make up a nifty extension to the move and rotate commands...
Top
 Offline Profile  
 
PostPosted: 04 Dec 2010, 23:52 
Modeler
User avatar

Joined: 02 Jan 2008, 21:55
Just chiming in to say this is absolutely fantastic, great work Spliff. I especially like the native .blend support. :-)


What's the word on skeletal animation? Will it be supported or is that a down-the-road feature?
Top
 Offline Profile  
 
PostPosted: 05 Dec 2010, 05:51 
User avatar

Joined: 21 Feb 2005, 03:38
Location: Herding cats uphill whilst wearing roller skates.
Scaling / rotations / transforms can be done in the vertex shaders. You really should just get the Unit core position and produce the current Piece matrix, everything else should be shader-side. Ideally, we'd get rid of Pieces except as an abstraction, in the sense of just including the Piece number in the vertex's multitexcoord, along with a texture ID (ideally).

Up dir is going to be a pain in the ass. Please plan ahead. Models need to be pre-processed at runtime based on a tag (updir=X, basically), most likely, or we'll end up with, "gee, program X is a great animating tool, but presumes that Y is up, whereas Spring says Z is up", etc.

Just a thought- it's easier to deal with it now rather than later.

Glad to see that things are moving along otherwise.
Top
 Offline Profile  
 
PostPosted: 05 Dec 2010, 17:39 
Game Developer
User avatar

Joined: 25 Jun 2006, 07:44
Location: Germany
If you remove pieces like that then how do you determine where bullets come out?
Top
 Offline Profile  
 
PostPosted: 06 Dec 2010, 01:43 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
With Vertex Shader Magic Fairy Dust of course. To make Argh happy we're just going to rewrite the entire Spring engine as a shader because shaders solve everything.

With regards to the whole scaling issue the big unresolved issue is actually whether there's a desire for synced animation tracks. Having scaling support in synced "Piece" system is basically a prerequisite if you want your imported animations and un-applied transforms to affect aiming and attachment points. I suspect there may need to be two parallel animation systems and functions in synced/unsynced to seperate "physical" animations from purely decorative ones (like jK's vertex animated shark unit). However even without animation support you basically have only 3 options when it comes to handling scaling data in the model or metafile:

1.) Throw away scaling data and hope for the best
2.) Scale mesh data by iterating over the vertices and moving them.
3.) Pass the scaling data in the piece and handle it it the same way as rotations and offsets.

I chose 3. because it's the least likely to break animation tracks and normals. It's also the best option for manipulating models through metadata. It does as jK pointed out add some complexity to certain Lua functions and COB/Lua internals.

Anyway I was hoping to finish this weekend but I got drunk instead. I'll have a go this weekend and try and get a Win32 binary up for testers. The biggest obstacle right now is I'm getting rotations happening around the wrong axis and there seems to be something odd with how the engine accumulates transforms along the piece hierarchy (even when they aren't being scaled). I have no idea which way is correct so there'll be some trial and error I think.

BTW, I appreciate the congratulations but I want to point out that Kloot and BrainDamage have made significant contributions to make this happen. It isn't just a one-man show.
Top
 Offline Profile  
 
PostPosted: 07 Dec 2010, 09:20 
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
SpliFF wrote:
Basically, yeah. Here's a sample metafile. All values (the whole file even) are optional. Any missing data uses defaults based on model data
He, that looks nice. It annoyed me a bit that .s3o is not human readable that you can not ie see what texture is asigned to a model. So the tex1 = "duck.png", thing is very nice.
Also setting origins of pieces (i assume thats the offset and rotate stuff) in textfile seems like a good idea. Though there should probally be some export to lua thing in Upspring, otherwise it would be just guessing numbers.
Top
 Offline Profile  
 
PostPosted: 07 Dec 2010, 10:55 
MechCommander Developer
User avatar

Joined: 21 May 2007, 01:09
Location: New Zealand
knorke wrote:
It annoyed me a bit that .s3o is not human readable that you can not ie see what texture is asigned to a model.


Bzzt, RONG. At the very 'end' of the file, if you open it up in notepad (or whatever) the textures are right there.

Last line of a randomly picked .s3o...
Code:
 ┬ØÔÇ║                                Ôé¼      p├Çlmissleflare \ÔÇ║ ┬ÀÔÇí ├Á P* mg (  p2  ┬ìo  ├à┬ú  ┬╗ trifighter.tga trifighter2.tga
Top
 Offline Profile  
 
PostPosted: 07 Dec 2010, 21:38 
Spring Developer
User avatar

Joined: 28 Jun 2007, 06:30
SpliFF wrote:
...

If you don't trust me, then perhaps you may trust others:
http://hacksoflife.blogspot.com/2010/11/change-of-basis-revisited.html

To be more specific when you support scaling, you need always to create a special 3x3 matrix for the normal vector transformations (without scaling it is the upper-left 3x3 of the 4x4 ModelViewMatrix used for the vertices), also calculating the inverse of the matrix becomes much more complex (without scaling it is the transpose of the ModelViewMatrix).

PS: Also disallowing scaling doesn't mean that you couldn't scale the model at loadtime.
Top
 Offline Profile  
 
PostPosted: 08 Dec 2010, 01:16 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
Thanks for the link. It isn't that I don't trust you, it's just that I want to weigh up the trade-offs (because there are pros and cons here).

I guess if people have got by without scaling support this long there's no need to rush to a decision. I'm happy to leave out scaling support until someone decides to tackle animation (which is where it'll really be needed). Until then I guess I can just pre-transform and adjust the normals so at least modellers won't have to pre-apply the transforms.

Right now my priority is to get this tested and merged into the official branch so whatever makes that easier works for me. There's no reason additional features can't be added later.
Top
 Offline Profile  
 
PostPosted: 08 Dec 2010, 04:28 
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
Pressure Line wrote:
At the very 'end' of the file, if you open it up in notepad (or whatever) the textures are right there.
yes but you can not change it.
Top
 Offline Profile  
 
PostPosted: 17 Dec 2010, 10:30 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
SECOND BETA RELEASE

I'm pleased to announce the first second release of a working win32 binary with assimp support. This enables testing by a wider group of people. If you have any interest in seeing universal model support in Spring please help by testing this release and putting feedback and questions in this thread.

DOWNLOAD:
Windows (45MB):
FileFront
EvoRTS Server
Warriorhut (AUS)

Linux:
https://github.com/SpliFF/spring/tree/assimp-2.0

TESTING:
I have created a mod called AssimpTest which can be used for testing. It contains a range of models and units in various formats.
AssimpTest on Warriorhut (AUS 7.0MB)

To enable verbose logging edit your spring settings:
LogSubsystems=Model,Model-detail,Piece,Texture

To reload models and metadata without restarting Spring set:
NoModelCache=1
In SpringSettings or .springrc
This will cause the model to be reloaded every time a unit is created.

To spawn units:
/cheat
/give all (or whatever unitname you want)

METADATA FILE:
The optional lua metadata file goes in the same folder as your model called modelname.ext.lua or modelname.lua. For examples see the included ModelTest mod. The following properties are supported:

Code:
model = {
        radius = 25.0,
   height = 40,
   midpos = {0,-20,0}, -- model center offset
   tex1 = "corraid1_512.dds", -- same as S3O texture 1
   tex2 = "corraid2_512.dds", -- same as S3O texture 2
   invertteamcolor = true, -- invert tex1 alpha channel
   fliptextures = true, -- turn textures upside down
   pieces = {
      root = {
         rotate = {-90,0,0},
         offset = {10,0,0}
      },
      turret = {
         parent = "chassis",
         rotateZ = 30,
         offsetY = 20,
      }
   }
}
return model



MODEL CONVERSION:
The importer can handle S3O models converted through the blender import plugin created by thesleepless. Specifically it reads properties from scene objects SpringHeight (z-axis is height property) and SpringRadius (center is midpos, scale is radius. If scale is 1.0 then radius is x-axis of mesh). You should then export as Collada since Assimps' blender support is currently broken. Make sure you disable physics on the Collada 1.4 export screen as it seems to crash when the scene contains empty nodes like those generated by the S3O import script.


KNOWN BUGS / LIMITATIONS:
* Will crash if you destroy units. This is due to missing content in the included mod, not a code bug.
* Scale property on nodes not used. Apply your scaled nodes first (Spring limitation).
* Blender import broken. Child objects inherit parents transform incorrectly (assimp issue)
* No support for global transforms. All pieces must be positioned relative to their parent, not the scene. This may be a problem for non-hierarchical formats like OBJ.
* DDS textures can't be inverted or flipped
* When your unit starts moving the rotation appears to temporarily reset to 0.0 (the unit rocks backwards 90deg). Seems to affect some units, not all.
* Collision volume support not complete
* While the importer can provide animation and bone data the code for Spring to handle that data has not been written yet. In short, no animation support yet.
* No embedded materials / Textures support. Textures go in UnitTextures/ and work the same way as with S3O models. ie, Teamcolor is tex1 alpha and Shininess/glow etc are handled through tex2. The main difference is you can flip textures and alpha channel through metafile.
* Some formats like 3DS appear to crash if a node is created with no mesh (or an empty mesh). Either avoid empty nodes or use another format.


Last edited by SpliFF on 21 Feb 2011, 02:48, edited 7 times in total.
Top
 Offline Profile  
 
PostPosted: 17 Dec 2010, 21:35 
Community Representative
User avatar

Joined: 08 Sep 2008, 21:59
Location: small cars
*starts the slow clap*

seriously how can you guys let an announcement like this slip off the first page without a single response >.> son i am disappoint

thanks a ton spliff; i havent tested yet... but stuff like mesh deform and keyframed animation is now supported? is it easy to code spring to recognize and use such a format? any workflow or tips to suggest for someone interested in using your implementation for a project?

im pretty excited.
Top
 Offline Profile  
 
PostPosted: 17 Dec 2010, 22:22 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
i think the problem is, that this is the dev forum, and guys to test this are modders. maybe cross link it there.

edit: congrats!
Top
 Offline Profile  
 
PostPosted: 17 Dec 2010, 23:28 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
*rapturous applause*
Top
 Offline Profile  
 
PostPosted: 18 Dec 2010, 00:01 
Modeler
User avatar

Joined: 13 May 2008, 15:51
Location: Universe
Make a new topic, that will get the attention.
Top
 Offline Profile  
 
PostPosted: 18 Dec 2010, 00:01 
Modeler
User avatar

Joined: 13 May 2008, 15:51
Location: Universe
Uh, double post? There's this annoying thing that if you double click the submit button your post goes in twice.
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 140 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: Yahoo [Bot] and 0 guests


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.