Integrating alternate model formats

[SpliFF]

but thats beside the point. either completing the md5 model support (bones plz?) and/or making s3o better (multiple textures per unit plz?) would probably be time better spent imo. but thats just me :)

The assimp scene data structure supports both features, using that data is the challenge.

[Pressure Line]

technically s3o supports multiple textures too. its just a matter of someone writing the lua to do it...

[SpliFF]

Don't you mean the C++? Anyway multitexturing is pretty old tech, shouldn't be too hard.

I'm surprised about s3o supporting multiple textures though, Upspring only allows 1 (not counting the specular/glow/alpha one which is supported already)

[Tobi]

S3Os are already rendered with like 4 textures, so it's not like we don't have multitexturing

(Diffuse color texture, texture with teamcolor + reflectivity + something else channels, depth texture for shadow mapping and cube texture for reflection rendering.)

Integrating new model formats is a great idea in any case, but indeed, do abstract it a bit so only one or two files get exposed to the external dependency.

One thing I learned in Spring is that external deps are win for small projects because they save time, but the bigger your project gets the more pain they cause because they update slower then your project, they contain bugs for which - if you want to fix them - you have to include the entire dependency in your project, or join the team which develops the dependency too, etc. It's particularly nasty when the dependencies constantly break their APIs like *kuch*boost*kuch*.

[Kloot]

technically s3o supports multiple textures too. its just a matter of someone writing the lua to do it...

For the millionth time: the engine itself renders S3O's with FIVE textures (aka. multi-texturing), and such Lua shaders have already been written!

[Tobi]

Oh five even

[jcnossen]

I get the feeling people are talking about 2 different things here. There is rendering multiple textures on top of eachother (Which spring already does), and there is having multiple textures per s3o model, so you don't have to put all texturing in a single UV space. This is what spring does not do, and is also what Pressure Line talks about.
Maybe we should call it multimapping? :)

[Pressure Line]

Thanks jc (omg deus ex flashbacks) thats exactly what im talking about. (and is why I said 'multiple textures' and not 'multi-texturing' which are different things)

Via lua, s3o units can have multiple MAIN textures via a material system. The only problem is, afaik only jK and trepan know how to use it.

I did something almost 18 months ago which *does* work, but not in a particularly useful way (for that application anyway) i have found alternate uses for the code however, for which it works quite nicely.

[SpliFF]

UPDATE: I have the model loader integrated and compiling with Spring. I'm now working on making the loaded data compatible with Spring's model classes. This should result in loaded models being fully compatible with Spring's animation system which means they can be used for units as well as features.

I'm going to add some new FBI tags as well. The tags will allow certain spring-specific data to be specified in the unit data rather than the model itself.

Tags include:

CenterX -- X offset of model center
CenterY -- Y offset of model center
CenterZ -- Z offset of model center
Radius -- Radius used for basic sphere collision detection.
Height -- Height used for crushing and other things

All of these can be autodetected but the FBI tags allow you to override the detected values. In addition if a part called "base" is found then the values will be taken from that. Both methods are quicker and more accurate than scanning all vertices of the model to determine the extents.

Time to complete depends on my free time in the next few weeks but I'm guessing there's less than 10 hours of actual work involved. I'll update again with some screenshots when I've got the drawing routines worked out.

[Argh]

Hey, glad this is finally getting done. "Multimapped" models have been one of my wishlist items for a long, long time. And skeletal animation formats would really be a game-changer for this engine. Makes me want to work on a third race for P.U.R.E., if this ever gets done.

[SpliFF]

Whoa, just because it loads animations doesn't mean Spring will immediately support complex animation systems. Full bone support and physics etc may be a feature of certain model types but I'm not experienced enough to turn that data into working animations.

The best I can do for now is hook it up to COB. After that I'm going back to working on my mod.

[Argh]

So... uh... how are you going to display them?

[SpliFF]

I convert the meshes to named triangle strips (pieces) and add the triangles to an opengl display lists (accounting for rotations etc). Then I tell opengl where the textures go. COB takes care of moving the pieces.

You can add animations to your model but I don't know how to render them in a way that won't conflict with COB.

[Argh]

So, basically you're planning to draw them without shaders?

As for the COB connection... my feeling on this is that, given that nobody's released a Lua-based system, you could just have a COB callout via GET that specified the animation, the type, and any other parameters that pertained, and if the format handled blending or other stuff, "just" port the relevant code (i.e. port the Id Tech code for handling display of MD5s once loaded, for example). Only trouble would be the character not casting a shadow or reflection, because both things would require deeper changes... but we can live without either.

That should work, for the vast majority of tasks. Character's moving, but not aiming? Call this animation, sleep however long the cycle requires, repeat. Aiming, but not moving? Call another one. IOW, just handle character events and timing the same old way we already do.

If using the MD5 code from the Quake source to handle blending and other crap, it should be possible. Now, will this stuff do what COB can do- complex procedural animations? No, it won't. But that's always going to be the real tradeoff anyhow, given that normalmaps and other shader stuff for Units is going to be possible in the next version of Spring.

I know that I'm way, way, way over-simplifying what must be a terrifically challenging task. And no, I have no idea how to go about it. But it seems to me that just loading them and sticking a single texture on them is not really going to cut it.

[SpliFF]

This has nothing to do with shaders.

Animation is not as simple as copying quake code. Either way I'm not doing it. I'm hooking the static meshes into Spring's existing system and adding a way to set some of s3o's properties without changing the model. Nothing more.

The animation data will be available if someone wants to extend it later.

[Pressure Line]

In addition if a part called "base" is found then the values will be taken from that.

I'd rather have it read it from the fbi/lua file. I usually have the 'base' piece sitting at 0 0 0, but I don't necessarily intend for that to be the centre of the unit, because if rather have other units aim at the centre of its torso than at its feet.

[SpliFF]

I'll call the piece 'hitbox' instead. The FBI values override the hitbox as well as autodetect so you can always override using the unit file.

[jK]

erm do you even know how the current collision volume system works?
-> your FBI stuff (there isn't even any FBI anymore) is already integrated

[SpliFF]

No I don't know how the current collision system works. I'm still working on converting the vertices and textures. What I've seen of the collision system is complex and has minimal obvious documentation.

Anyway, regardless of the collision system the 3DModel class still requires a midpos , a radius, a height and min/max x/y/z values. Are you saying I can just leave all of these set to 0 if a collision volume is defined? If not then what are these values being used for? Shouldn't the model radius and height just be converted directly to a collision volume?

Code: Select all

struct S3DModel
{
	S3DModelPiece* rootobject;
	int numobjects;
	float radius;
	float height;
	std::string name;
	int farTextureNum;
	float maxx,maxy,maxz;
	float minx,miny,minz;
	float3 relMidPos;
	int type;        //! MODELTYPE_3DO, MODELTYPE_S3O, MODELTYPE_OTHER
	int textureType; // FIXME MAKE S3O ONLY      //0=3do, otherwise s3o
	std::string tex1;
	std::string tex2;
	inline void DrawStatic() const { rootobject->DrawStatic(); };
};

As a new developer I have no easy way of knowing what is legacy and what isn't without searching through the source and SVN comments. Even then it's easy to miss something. Don't be so quick to cry RTFM when you still don't really have one and your code comments are few and far between.

So anyway, if collision volumes are the new way of doing things then is there any harm in moving min/max/height/radius properties out of the model class and into a CollisionVolume where they apparently belong?

EDIT: What I do know is that the min/max values can be read via a lua function so I have to calculate them regardless. Don't know about radius and height though.

EDIT AGAIN: WorldObject needs the radius too. Clearly the model extents have more uses than collision detection so I'm going to go ahead and implement these tags. It also looks like the unitDef handler can read a vector so I can make the offset 1 tag rather than 3.

Offset = {0.0, 0.0, 0.1}, -- x,y,z

[Argh]

Anyway, regardless of the collision system the 3DModel class still requires a midpos , a radius, a height and min/max x/y/z values. Are you saying I can just leave all of these set to 0 if a collision volume is defined?

Using a default value of 8.0 for all values besides midpos should be safe and work just fine.