Integrating alternate model formats
Moderator: Moderators
Re: Integrating alternate model formats
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.
Re: Integrating alternate model formats
Yeah, sounds like what I envisioned would be the best solution.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.
Re: Integrating alternate model formats
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).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).
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.
Re: Integrating alternate model formats
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:
And the entirety of the rendering changes is basically:
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..
Code: Select all
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;
}
Code: Select all
if (scale.x!=1.0f || scale.y!=1.0f || scale.z!=1.0f) { glScalef(scale.x, scale.y, scale.z); }
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..
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Integrating alternate model formats
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...
Re: Integrating alternate model formats
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?
What's the word on skeletal animation? Will it be supported or is that a down-the-road feature?
Re: Integrating alternate model formats
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.
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.
Re: Integrating alternate model formats
If you remove pieces like that then how do you determine where bullets come out?
Re: Integrating alternate model formats
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.
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.
Re: Integrating alternate model formats
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.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
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.
- Pressure Line
- Posts: 2283
- Joined: 21 May 2007, 02:09
Re: Integrating alternate model formats
Bzzt, RONG. At the very 'end' of the file, if you open it up in notepad (or whatever) the textures are right there.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.
Last line of a randomly picked .s3o...
Code: Select all
┬ØÔÇ║ Ôé¼ p├Çlmissleflare \ÔÇ║ ┬ÀÔÇí ├Á P* mg ( p2 ┬ìo ├à┬ú ┬╗ trifighter.tga trifighter2.tga
Re: Integrating alternate model formats
If you don't trust me, then perhaps you may trust others:SpliFF wrote:...
http://hacksoflife.blogspot.com/2010/11 ... sited.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.
Re: Integrating alternate model formats
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.
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.
Re: Integrating alternate model formats
yes but you can not change it.Pressure Line wrote:At the very 'end' of the file, if you open it up in notepad (or whatever) the textures are right there.
Re: Integrating alternate model formats
SECOND BETA RELEASE
I'm pleased to announce thefirst 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:
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.
I'm pleased to announce the
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: Select all
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.
Re: Integrating alternate model formats
*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.
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.
Re: Integrating alternate model formats
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!
edit: congrats!
Re: Integrating alternate model formats
*rapturous applause*
Re: Integrating alternate model formats
Make a new topic, that will get the attention.
Re: Integrating alternate model formats
Uh, double post? There's this annoying thing that if you double click the submit button your post goes in twice.