Integrating alternate model formats
Moderator: Moderators
Re: Integrating alternate model formats
Out of curiosity does Spring have a debug option to render collision volumes, radiuses, footprints and heights?
Re: Integrating alternate model formats
Press B in game to display collision volumes (only ellipsoid, box, cylinder, the footprint type is rendered as a sphere).
Enable cheating and press F2 while having a unit selected to view an interpretation for that unit of the groundBlockingObjectMap. This is the closest you'll be able to get to the footprint of everything.
Enable cheating and press F2 while having a unit selected to view an interpretation for that unit of the groundBlockingObjectMap. This is the closest you'll be able to get to the footprint of everything.
Re: Integrating alternate model formats
Haven't updated this thread for a month but I have made some progress. The assimp library is fully integrated and I have a model-loader class that uses it. At the moment I need to finish the ModelPiece initialisation and then update the UnitDrawer class to perform the rendering. Time has been an issue due to lots of RL pressures.
Since the assimp library is still alpha there are some features I've found that don't work but I believe the core features and common formats are all there.
Since the assimp library is still alpha there are some features I've found that don't work but I believe the core features and common formats are all there.
Re: Integrating alternate model formats
I'm rezzing this thread because I'm resuming work on integrating the assimp library with Spring. This will enable Spring to directly load over 20 common 3D model formats including the big 3 (MD3, OBJ and 3DS). I had to postpone last year due to work pressures but I have some time now.
Before I stopped I made significant progress:
* Got assimp to integrate and build with Spring
* Taught assimp how to read files via Spring VFS
* Created a new 'ass' unit model type and loader
It won't take me long to sync my changes with the current Spring however that will still leave the problem of rendering. I have some generic rendering code to walk the faces of an Assimp scene but it'll take me awhile to get it connected up with Spring's rendering and collision systems.
My OpenGL and C++ knowledge is limited so I'm looking for some volunteers to help me with the rendering system hookup. Please PM if you are familiar with GL and/or Spring's unit rendering system and have some time this month to help me get this up and running.
There is no plan at this stage to implement any advanced features like animations or IK. This effort is aimed squarely at avoiding the time-consuming and bug-prone process of converting via 3ds and UpSpring each time a model is created or changed. However since Assimp supports the import of animation data this could be the first major step in bringing these features to Spring some time in the future.
Before I stopped I made significant progress:
* Got assimp to integrate and build with Spring
* Taught assimp how to read files via Spring VFS
* Created a new 'ass' unit model type and loader
It won't take me long to sync my changes with the current Spring however that will still leave the problem of rendering. I have some generic rendering code to walk the faces of an Assimp scene but it'll take me awhile to get it connected up with Spring's rendering and collision systems.
My OpenGL and C++ knowledge is limited so I'm looking for some volunteers to help me with the rendering system hookup. Please PM if you are familiar with GL and/or Spring's unit rendering system and have some time this month to help me get this up and running.
There is no plan at this stage to implement any advanced features like animations or IK. This effort is aimed squarely at avoiding the time-consuming and bug-prone process of converting via 3ds and UpSpring each time a model is created or changed. However since Assimp supports the import of animation data this could be the first major step in bringing these features to Spring some time in the future.
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Re: Integrating alternate model formats
i've successfuly managed to integrate assimp with spring actually, i started from your old branch and ended up rewriting 90% of it , it's only lacking material support now
http://github.com/BrainDamage/spring/tree/assimp
http://github.com/BrainDamage/spring/tree/assimp
Re: Integrating alternate model formats
oh sweet can i have have a nudeversion for PA?daan 79 wrote:
compatible model
Re: Integrating alternate model formats
Just posting to compliment on your current work and urge you guys on.
C'mon! Alternate model formats FTW!
C'mon! Alternate model formats FTW!
Re: Integrating alternate model formats
yeah i really want skeletal for my pronz mod makes much better tit anims.
Re: Integrating alternate model formats
See what he did there? It's a model, but it could also easily be a model! Oh dear.d_b wrote:oh sweet can i have have a nudeversion for PA?daan 79 wrote:
compatible model
Re: Integrating alternate model formats
Ah, those younglings, they can't do anything without being spoon-fed. Back in ye ole TA days, we made tit anims in BOS!d_b wrote:yeah i really want skeletal for my pronz mod makes much better tit anims.
Click here to enlarge your tits!
Re: Integrating alternate model formats
Yes Z, I remember your santa claus and that revolutionary butterfly.
Re: Integrating alternate model formats
Back again. This time with major progress towards a first testing release.
Supported features:
* Successfully imports all tested formats. So far that's Collada, 3DS, OBJ, LWO, MD2, MD3 and X (DirectX). Most other Assimp formats should work bringing the number of supported model formats to around 20. S30/3DO are still supported through their native loaders.
* Correctly maps textures provided the model uses a single external UV map.
* Texture fallback so Spring can run with missing textures.
* New Log Subsystems: Model, Model-detail, Piece, Piece-detail and Texture for comprehensive debugging of import problems
* Adds support for lua metafile (Compatible with Kloot's OBJ Lua specification) so you can optionally override default handling of model properties. Currently supported properties are:
invertteamcolor = <bool> -- reverses the alpha channel so normal textures look correct
fliptextures = <bool> -- flips the textures upside down to match the OpenGL coordinate system.
radius -- radius used by spring for some calculations
height -- height used by spring for some calculations
offset -- shift the model in X,Y,Z for proper alignment
tex1 -- specular and team color
tex2 -- glow, reflection, alpha
Planned support for:
lua scaling vector
lua rotation vector
custom piece transforms
lua shader specification
multi-texture / UV's per model
Embedded textures
Known problems:
Untested with COB/Lua animations.
Limited collision volume testing.
Requires a file called unittextures/default.png for texture fallback support.
There's no real agreement in 3D about where the "front" of an object is or how big it is so you may see models facing the wrong way or the wrong scale. To be fixed with lua metafile transforms when I can figure out how to transform objects safely.
Lua radius/height currently being ignored
Screenshots of successfully imported models:
MD2 chick
Collada Duck
3DS tanks converted from S3O
MD3 showing texture fallback
DirectX Dwarf (1 UV only)
The latest code can be found at:
http://github.com/SpliFF/spring/tree/assimp-1.1
Supported features:
* Successfully imports all tested formats. So far that's Collada, 3DS, OBJ, LWO, MD2, MD3 and X (DirectX). Most other Assimp formats should work bringing the number of supported model formats to around 20. S30/3DO are still supported through their native loaders.
* Correctly maps textures provided the model uses a single external UV map.
* Texture fallback so Spring can run with missing textures.
* New Log Subsystems: Model, Model-detail, Piece, Piece-detail and Texture for comprehensive debugging of import problems
* Adds support for lua metafile (Compatible with Kloot's OBJ Lua specification) so you can optionally override default handling of model properties. Currently supported properties are:
invertteamcolor = <bool> -- reverses the alpha channel so normal textures look correct
fliptextures = <bool> -- flips the textures upside down to match the OpenGL coordinate system.
radius -- radius used by spring for some calculations
height -- height used by spring for some calculations
offset -- shift the model in X,Y,Z for proper alignment
tex1 -- specular and team color
tex2 -- glow, reflection, alpha
Planned support for:
lua scaling vector
lua rotation vector
custom piece transforms
lua shader specification
multi-texture / UV's per model
Embedded textures
Known problems:
Untested with COB/Lua animations.
Limited collision volume testing.
Requires a file called unittextures/default.png for texture fallback support.
There's no real agreement in 3D about where the "front" of an object is or how big it is so you may see models facing the wrong way or the wrong scale. To be fixed with lua metafile transforms when I can figure out how to transform objects safely.
Lua radius/height currently being ignored
Screenshots of successfully imported models:
MD2 chick
Collada Duck
3DS tanks converted from S3O
MD3 showing texture fallback
DirectX Dwarf (1 UV only)
The latest code can be found at:
http://github.com/SpliFF/spring/tree/assimp-1.1
Last edited by SpliFF on 26 Sep 2010, 17:48, edited 1 time in total.
Re: Integrating alternate model formats
Glad to see progress being made =) Keep up the good work!
-
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Integrating alternate model formats
Great news!
Re: Integrating alternate model formats
Great news indeed. Also glad to see you decided to leave native 3do and s3o loaders alone.
Re: Integrating alternate model formats
Update
Very close to formal test release now. I just updated to Assimp 2.0 which adds native .blend (Blender) support to the mix. That means if you model in Blender you no longer need to use an export script.
Transforms are now supported in the lua metafile if you want to rotate, offset or scale pieces without touching the actual model.
I've added a tweak to the engine which allows mod devs to disable the model cache. This lets you rapidly prototype because now you can see changes to your models without restarting the game. All you need to do is create a new unit and the modified model will be used.
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).
The only thing really holding this up now is some oddities in the results from models with transforms. I'm pretty sure it's because Spring has a different concept of which way is "up" and "forward" to Assimp and/or Blender. In Blender up is +Z and "forward" seems to be -Y. I'm still not entirely sure what Spring uses. The issue is complicated slightly because Assimp throws in a 90deg rotation on the Z axis which seems to imply it thinks Blender is wrong. I'll figure it out later when I'm less tired. If someone can shed some light on Spring's coordinate system in the meantime that would be good too.
As usual the code is up on my github page. The most up-to-date branch is assimp-2.0 (not master).
Same 2 models loaded several times with different scale/rotation properties in metadata.
Very close to formal test release now. I just updated to Assimp 2.0 which adds native .blend (Blender) support to the mix. That means if you model in Blender you no longer need to use an export script.
Transforms are now supported in the lua metafile if you want to rotate, offset or scale pieces without touching the actual model.
I've added a tweak to the engine which allows mod devs to disable the model cache. This lets you rapidly prototype because now you can see changes to your models without restarting the game. All you need to do is create a new unit and the modified model will be used.
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).
The only thing really holding this up now is some oddities in the results from models with transforms. I'm pretty sure it's because Spring has a different concept of which way is "up" and "forward" to Assimp and/or Blender. In Blender up is +Z and "forward" seems to be -Y. I'm still not entirely sure what Spring uses. The issue is complicated slightly because Assimp throws in a 90deg rotation on the Z axis which seems to imply it thinks Blender is wrong. I'll figure it out later when I'm less tired. If someone can shed some light on Spring's coordinate system in the meantime that would be good too.
As usual the code is up on my github page. The most up-to-date branch is assimp-2.0 (not master).
Same 2 models loaded several times with different scale/rotation properties in metadata.
Re: Integrating alternate model formats
Very neat.
+y is up, +z is forward, in Upspring, I assume same is true of Spring.
+y is up, +z is forward, in Upspring, I assume same is true of Spring.
Re: Integrating alternate model formats
so that means that models can be scaled without having to use ie upspring just by editing a .lua file?
like a unit def:
model=blatank.s3o
modelsize=5.0
And possible even reloads on doing /luarules reload (or similiar)?
That would be cool.
like a unit def:
model=blatank.s3o
modelsize=5.0
And possible even reloads on doing /luarules reload (or similiar)?
That would be cool.
Re: Integrating alternate model formats
Basically, yeah. Here's a sample metafile. All values (the whole file even) are optional. Any missing data uses defaults based on model data:
Code: Select all
model = {
radius = 25.0,
height = 40,
midpos = {0,-10,0},
tex1 = "duck.png",
pieces = {
root = {
rotate ={90,0,0},
scale = {2.0,2.0,2.0},
},
hitbox = {
hidden = true,
collide = "box",
},
chassis = {
offsetX = 30,
},
turret = {
parent = "chassis",
rotateX = 30
}
}
}
return model
Re: Integrating alternate model formats
Does it play nicely with usePieceCollisionVolumes?