Integrating alternate model formats - Page 4

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

Re: Integrating alternate model formats

Post by SpliFF »

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

Re: Integrating alternate model formats

Post by FLOZi »

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.
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Integrating alternate model formats

Post by jK »

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

Re: Integrating alternate model formats

Post by SpliFF »

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: 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;
}
And the entirety of the rendering changes is basically:

Code: Select all

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..
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: Integrating alternate model formats

Post by Master-Athmos »

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...
User avatar
Hobo Joe
Posts: 1001
Joined: 02 Jan 2008, 21:55

Re: Integrating alternate model formats

Post by Hobo Joe »

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

Re: Integrating alternate model formats

Post by Argh »

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.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: Integrating alternate model formats

Post by KDR_11k »

If you remove pieces like that then how do you determine where bullets come out?
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Integrating alternate model formats

Post by SpliFF »

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.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Integrating alternate model formats

Post by knorke »

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.
User avatar
Pressure Line
Posts: 2283
Joined: 21 May 2007, 02:09

Re: Integrating alternate model formats

Post by Pressure Line »

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

 ┬ØÔÇ║                                Ôé¼      p├Çlmissleflare \ÔÇ║ ┬ÀÔÇí ├Á P* mg (  p2  ┬ìo  ├à┬ú  ┬╗ trifighter.tga trifighter2.tga 
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Integrating alternate model formats

Post by jK »

SpliFF wrote:...
If you don't trust me, then perhaps you may trust others:
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.
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Integrating alternate model formats

Post by SpliFF »

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.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Integrating alternate model formats

Post by knorke »

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

Re: Integrating alternate model formats

Post by SpliFF »

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: 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.
User avatar
KaiserJ
Community Representative
Posts: 3113
Joined: 08 Sep 2008, 22:59

Re: Integrating alternate model formats

Post by KaiserJ »

*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.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Integrating alternate model formats

Post by hoijui »

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!
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Integrating alternate model formats

Post by AF »

*rapturous applause*
User avatar
Hoi
Posts: 2917
Joined: 13 May 2008, 16:51

Re: Integrating alternate model formats

Post by Hoi »

Make a new topic, that will get the attention.
User avatar
Hoi
Posts: 2917
Joined: 13 May 2008, 16:51

Re: Integrating alternate model formats

Post by Hoi »

Uh, double post? There's this annoying thing that if you double click the submit button your post goes in twice.
Post Reply

Return to “Engine”