Spring RTS Engine

BrainDamage and I have been working a new model importer for Spring. We have model loading and flat color (grey) rendering working for all major 3D formats (obj, 3ds, collada, mdl, md3, md5, etc...). Since I don't do a lot of modelling myself I thought I'd get some feedback here on how to proceed.

Textures

I'm currently working on texturing, which is a very tricky area. I'm going to lay down what i THINK i know so you guys can correct me where i'm wrong.

Spring's current texture loading is done in 2 ways. The 3DO format uses a texture atlas and the S3O format uses UV mapping. It's my understanding that UV mapping is the most common approach for modern games so I'll focus on that. It appears that S3O actually uses 2 textures, where the second texture contains teamcolor alpha, glow and shininess properties in the channels.

What is the relationship between a 'material' and a 'texture' in common 3d models? The import library exposes both as seperate (but possibly related) objects. If I understand correctly a material can be applied in most 3d packages and gives each face it is applied to a fixed diffuse, specular, ambient, emissive and shininess value. Presumably the combination of these things, particularly the diffuse value, creates the 'color' in the case where there is no texture. In the case where there is one or more textures these values affect the texture as well (kind of blended with the texture's actual color values). Does anyone actually need flat color (vertex colors) for modelling these days or can flat color materials simply be ignored?

A model with a texture presumably supplies a set of texcoords which opengl uses to work out which parts of the texture go where. What is the relationship between texcoords and mesh vertices? Are there always 4 texcoords per face or does it depend on the faces type (tri or quad).

I've made an S3O model using open-source tools (Wings / Gimp / Paint.Net) and I found the 4-channel second texture rather awkward to work with, largely because the 4th channel (teamcolor) is the images' alpha and messing with it makes the image look really odd and the process requires accessing channels directly. Since the import library exposes 'materials' how easy are materials to work with. Can any of the material channels be used for team color or would this require editing the geometry? How do other common model formats and games handle special cases like teamcolor?

Can multitexturing be used for this purpose? Is it supported by common formats? Is it difficult to render?

Do any modelling tools or formats support GL shader programs directly in the model? Is there any point supporting this or should it be left to mods to implement via Lua?

Hitboxes / Heights / Footprints

Now the whole point of the model loader is to use models 'as is' not passed through another tool (UpSpring). This has obvious benefits to workflow and cross-platform development. However it also removes the tools normally used to set the models dimensions for the purposes of selection, pathing and collisions. The options appear to be:

1.) Create a hidden node named 'hitbox' in the scene
2.) Set the values in the unit fbi/lua.

So thoughts on which is best for each required value would be useful.

Nodes and Meshes

The assimp library splits a model into nodes and meshes. Nodes can have 0 or more meshes and nodes can share meshes. I'm currently creating a 1-to-1 relationship between nodes and Spring's 'pieces'. Are there any issues with that approach? Are there any formats or modelling tools that would have issues naming or creating nodes (which is needed for cob/lua animations)?

Rotation

I've noticed one of the 3ds models loads with its 'front' facing the ground. I'm going to assume this model is actually the right way round in 3D Studio. Is this common? Is the model wrong or is Spring? Do we need a way to remap the axis in the unit fbi/lua?

Anything else?

Apart from asking for bones/animation support (which I personally won't be doing) are there any other requirements you need?

Can you help?

If you are a GL guru or can assist with testing let me know. All the source for this 'assimp' branch is pushed to my github repo regularly. I also have a test mod with units using various formats uploaded to my site. PM or post if you can assist.

PS. Just this once can we all stay on topic. These issues are complicated enough without dealing with all the usual bullshit. Also any 'support' posts telling me how happy you are, please keep it to yourself or PM. Thanks.

Texturing: simply import it per its specification.

Engine will need to deal with specifics. Some model formats explicitly support multitexturing (more than one texture assigned to one or more areas of geometry... technically S3Os are "multitextured" in terms of how the renderer deals with them) some formats can't. Don't try to force everything to behave like S3O, that will cause a lot more problems than it solves (for example, I'm already using 3 textures per model, the S3O specification is going to become increasingly meaningless as shaders take over).

UVs are just texture coordinates and normal vectors for a given triangle / quad; how this is specified exactly varies from format to format.

Are there always 4 texcoords per face

Yes, and a normal vector, IIRC.

Do any modelling tools or formats support GL shader programs directly in the model?

Collada might; MD5 can have a variable for what shader to use for that section of the geometry, IIRC. Each model format is going to differ a lot, because they're dealing with very different requirements.

Hitboxes, etc.; don't worry about that in the model, at least not until you feel like building a visual editor for a given format. Coding it for a given Unit is straightforward.

I'm currently creating a 1-to-1 relationship between nodes and Spring's 'pieces'. Are there any issues with that approach?

Yes. Let's say you have a 'biomechanical' humanoid MD5 mesh. The "arm" node is part of a visually-contiguous mesh for the entire model, but contains 3 sub-meshes- "skin", "metal", and "glow". Each is expecting to use a different shader. If they're all treated the same, that will cause a lot of issues down the road.

I've noticed one of the 3ds models loads with its 'front' facing the ground. I'm going to assume this model is actually the right way round in 3D Studio. Is this common?

Yes, this is going to be a very common problem. Different 3D editing suites can use right-handed or left-handed coordinate systems, different scales, etc. That's a problem modelers can deal with.

Can multitexturing be used for this purpose? Is it supported by common formats? Is it difficult to render?

No more difficult than other rendering. It comes with pluses and minuses in terms of performance vs. ease of use.

What is the relationship between a 'material' and a 'texture' in common 3d models?

All a "material" is... is a series of variables that are expected to be obeyed in a certain way, such as the stuff you mentioned (diffuse, specular, etc.). Basically that stuff is 100% useless on the engine side, other than shader / texture references in formats like MD5. We aren't going to want simple Phong shading for new model formats, and old formats like OBJ basically assume that it would be helpful to have all that information, but it's basically useless for something like Spring, where we basically just need the geometry, animation data, texture references, and shader references.

Also, it sounds like you and Kloot and Tobi and Trepan should get on the same page about all this stuff, since you've all been working on various parts of this problem. If we have a reasonable import pipeline and we can display MD5, then we're going to need code, probably borrowed from BZFlag, to deal with the animations and render things properly in the engine. Otherwise... well, I for one would love to have a generic system to call up arbitrary mesh data at runtime that isn't a "unit", but that's obviously just one piece of the puzzle, and it would be good for everybody to understand what goals have been set and who's doing what.

Kloot wrote a MD5 importer in Lua that appeared to meet most of the actual requirements for both reading the files and displaying them; the problem there was / is that animation support still doesn't exist for dealing with things. I am on record as saying 'just let us call animations via COB-->Lua, and don't worry about whether it is physically accurate or w/e', which is what I still think should be done, since otherwise we may have to wait a decade for something to happen.

Lastly, the main goal is MD5 or MD3 support, imo. MD3 + shaders would probably be acceptable, but IIRC KDR_11K said that it's animations weren't CPU-efficient, so that may be an issue. IDK anything about that stuff, so you should probably solicit some free advice from the people around here who do know which of the two GPL'd id formats might be more suitable, since it's very unlikely anybody wants to write a new one from scratch and once we're committed to a animation format, that's probably going to remain the standard for a long time to come.

Anyhow, hope that was helpful, but for the technical end of this, Kloot / jK / jcnossen / trepan would all be people to talk to, especially Kloot, since what you're talking about may indeed be reinventing a wheel that already exists, just without certain engine support to Make It Work.

SpliFF wrote:Textures
Spring's current texture loading is done in 2 ways. The 3DO format uses a texture atlas and the S3O format uses UV mapping. It's my understanding that UV mapping is the most common approach for modern games so I'll focus on that. It appears that S3O actually uses 2 textures, where the second texture contains teamcolor alpha, glow and shininess properties in the channels.

just to know:
3do and s3o uses the SAME OpenGL-setup in Spring since a few versions.
So both use the same shaders, lighting, ... It's just that 3do uses only 1 texture atlas for all models (this atlas also contains a s3o-like tex2 with self-illum&reflection!) and that 3do disables culling.
Except that they are 100% the same -> a long time ago there was a discussion that spring would use different lighting in 3do&s3o, this is now 100% _not_ the case - and wasn't before either (it's just that most ppl misuse the self-illum&refl in tex2).

SpliFF wrote:What is the relationship between a 'material' and a 'texture' in common 3d models?

Materials are obsolete with shaders, ignore them. Just extract the texture paths.
Note: The rendering of the model with those textures can be complicated, because a model can use different textures for each piece/mesh. So you have to change the texture binding DURING the rendering, while the current renderer binds the texture before it renders the model. Also some lua widgets rely on raw-rendering of the models -> rendering a model w/o any textures, so you can't just put the texture bindings in the DisplayLists, if you do you have to create a 2nd DisplayList w/o those.

SpliFF wrote:A model with a texture presumably supplies a set of texcoords which opengl uses to work out which parts of the texture go where. What is the relationship between texcoords and mesh vertices? Are there always 4 texcoords per face or does it depend on the faces type (tri or quad).

Texcoords are so called "Vertex Attributes", means each vertex can/must have an own attribute value. When the GPU rasterize a polygon, it blend those attributes for each pixel/fragment. Normally the GPU always works with triangles (even when other face types are given), so for each pixel it blends 3 of those vertex attributes.
In OpenGL a vertex can have upto 7 texcoords + a lot of other vertex attributes as color,fogcoord,spec_color,...
And btw materials (they define some lighting factors) aren't vertex attributes, they are uniforms, means they are applied on a whole mesh -> no interpolation.
Per-vertex coloring is ... very old-school nobody uses it anymore, you can drop it.

SpliFF wrote:I've made an S3O model using open-source tools (Wings / Gimp / Paint.Net) and I found the 4-channel second texture rather awkward to work with, largely because the 4th channel (teamcolor) is the images' alpha and messing with it makes the image look really odd and the process requires accessing channels directly. Since the import library exposes 'materials' how easy are materials to work with. Can any of the material channels be used for team color or would this require editing the geometry? How do other common model formats and games handle special cases like teamcolor?

Normally yuse 2 different programs to create the model and the textures. And you save each texture layer (diffuse,specular,normal,self-illum,reflection,extra/teamcolor) in a separate image and _then_ you combine them via external tools to the texture format the engine/shader expects.

SpliFF wrote:Can multitexturing be used for this purpose? Is it supported by common formats? Is it difficult to render?

? it is always multitexturing .. duno where your issue is.

SpliFF wrote:Do any modelling tools or formats support GL shader programs directly in the model? Is there any point supporting this or should it be left to mods to implement via Lua?

Don't implement per-model shaders yet, it needs a huge renderer rewrite.

SpliFF wrote:Hitboxes / Heights / Footprints
Now the whole point of the model loader is to use models 'as is' not passed through another tool (UpSpring). This has obvious benefits to workflow and cross-platform development. However it also removes the tools normally used to set the models dimensions for the purposes of selection, pathing and collisions. The options appear to be:

1.) Create a hidden node named 'hitbox' in the scene
2.) Set the values in the unit fbi/lua.

So thoughts on which is best for each required value would be useful.

Please don't use any hacks please (special named hidden nodes etc.). You already have to calculate the radius of the model, just use that by default. Customization is the job of UnitDef/Lua.

SpliFF wrote:Nodes and Meshes
The assimp library splits a model into nodes and meshes. Nodes can have 0 or more meshes and nodes can share meshes. I'm currently creating a 1-to-1 relationship between nodes and Spring's 'pieces'. Are there any issues with that approach? Are there any formats or modelling tools that would have issues naming or creating nodes (which is needed for cob/lua animations)?

There is no problem with it as long as there is no plan for an engine driven animation system.

SpliFF wrote:Rotation
I've noticed one of the 3ds models loads with its 'front' facing the ground. I'm going to assume this model is actually the right way round in 3D Studio. Is this common? Is the model wrong or is Spring? Do we need a way to remap the axis in the unit fbi/lua?

There is no wrong here. Just ignore it. Modelers know how to fix it.

Argh wrote:

Are there always 4 texcoords per face

Yes, and a normal vector, IIRC.

read my answer above

Argh wrote:

I'm currently creating a 1-to-1 relationship between nodes and Spring's 'pieces'. Are there any issues with that approach?

Yes. Let's say you have a 'biomechanical' humanoid MD5 mesh. The "arm" node is part of a visually-contiguous mesh for the entire model, but contains 3 sub-meshes- "skin", "metal", and "glow". Each is expecting to use a different shader. If they're all treated the same, that will cause a lot of issues down the road.

your answer has nothing to do with his question ...

Argh wrote:..Spring, where we basically just need the geometry, animation data, texture references, and shader references.

Argh wrote:Also, it sounds like you and Kloot and Tobi and Trepan should get on the same page about all this stuff, since you've all been working on various parts of this problem. If we have a reasonable import pipeline and we can display MD5, then we're going to need code, probably borrowed from BZFlag, to deal with the animations and render things properly in the engine. Otherwise... well, I for one would love to have a generic system to call up arbitrary mesh data at runtime that isn't a "unit", but that's obviously just one piece of the puzzle, and it would be good for everybody to understand what goals have been set and who's doing what.

Kloot wrote a MD5 importer in Lua that appeared to meet most of the actual requirements for both reading the files and displaying them; the problem there was / is that animation support still doesn't exist for dealing with things. I am on record as saying 'just let us call animations via COB-->Lua, and don't worry about whether it is physically accurate or w/e', which is what I still think should be done, since otherwise we may have to wait a decade for something to happen.

Lastly, the main goal is MD5 or MD3 support, imo. MD3 + shaders would probably be acceptable, but IIRC KDR_11K said that it's animations weren't CPU-efficient, so that may be an issue. IDK anything about that stuff, so you should probably solicit some free advice from the people around here who do know which of the two GPL'd id formats might be more suitable, since it's very unlikely anybody wants to write a new one from scratch and once we're committed to a animation format, that's probably going to remain the standard for a long time to come.

He said he will not write an animation system! period.

Teamcolour? In one case at least i've seen md3's with a seperate teamcolour texture, in black and white, using the same uvmap (same way spring does tex 1 and 2). I dont know which is the superior choice here. Alpha channels certainly make textures harder to figure out how to end, but they keep them all in one file.

For uvmapping, in wings at least material tends to dictate which uv is used. If there is more than one texture per model (not how spring does it with tex1 and tex2, but like having the base of a tank on one texture and the turret on another) material is what defines which texture is used on which polygon. A lot of models are made with more than one texture, and it would allow for a lot more versatility (say, one infantry unit with many guns). It is not strictly necessary, but id say it would be a desired feature.

Hitboxes / Heights / Footprints
Almost certainly 2. In fact, you can already set custom collision volumes, though the model radius is still used for some things (As i recently found out D:). Footprint is defined entirely in unitdefs so thats not a problem, radius and height are the required tags.

Nodes and Meshes
Not sure about most of this but 'pieces' certainly cant share a mesh.

Anything else?
Yes, hierarchies. You need piece hierarchies for traditional per-piece style animation. Secondly pivot points, and the same. I've been told Blender is capable of setting these up, but i dont use it. I do not believe Wings is capable of doing these, so its sort of a case of 'Everything i use Upspring for now (pivots, heirarchies, hitsphere size, pieces and their names), i will have to use a third party program for anyway'.

(10:32:01 PM) spliffff: the texture code in Spring uses the term 'far texture' a lot but I can't find that term in any GL doco or tutorials. What does it mean exactly?
(10:34:10 PM) spliffff: the class doco just says "Cheap unit lodding using imposters"
(10:34:29 PM) spliffff: so i guess the question is "what's an imposter?"

Didn't get an answer so i'll ask the forum.

It just means 2D sprite, ie. a unit model rendered to a texture under various orientations and drawn (on a quad) instead of the model beyond a certain viewing distance.

An imposter is essentially an animated billboard iirc

Afaik "Unit Lod Distance" in the settings should make them show up soonish. Seems kinda broken for me though (I only get a few purple seams instead of a unit pic) and ever since radar symbols came up you don't really see it ingame anymore anyway...

If the pictures from the old gallery still exist somewhere you should be able to find some screenshots showing distant units as such "sprites". IIRC they simply were static shots of the unit and not animated though...

It just means 2D sprite, ie. a unit model rendered to a texture under various orientations and drawn (on a quad) instead of the model beyond a certain viewing distance.

I still think that should just be deprecated, it looks even more awful than showing nothing at all.

I could use that, actually, to solve some issues with 1944. It needs to be fixed, not removed.

It works over here, it's just that transparency is broken.

Imposters were broken with s3o since the format was first introduced afaik. Dunno if it has been fixed more recently, seem to recall it being mentioned. (kloot, maybe?)

Yeah, they work now, but without transparency they look really fugly. I'd rather see nothing, personally.

Well if they aren't transparent, I wouldn't exactly say they were working properly? Unless you mean specifically they don't maintain the transparency of the models' texture2?

Well, I guess that's "working" when you can see them at all, but no, without transparency they look really bad- little gray boxes everywhere. Very distracting because of pop-in.

That's why I'm basically of the opinion that it'd be better to just deprecate the feature and let people write a custom solution using Lua (which would probably be cheaper and more attractive, btw, because you could just use static representations and custom textures to represent the Unit in abstract- although there's little difference between that and radar dots at that point, other than better support of color).

And no, IDK about you but I don't care about tex2.

Yes, but most people do. Seeing as they use them.

Oops, I appear to have mis-communicated. I'm saying, "tex2 transparency doesn't need to be factored into building the imposters' alpha", is all.

None of the above statements are meant to be a discussion of any of the salient features of S3O's current specification. My apologies, if anybody thought I wanted to monkey around with S3O's base specification at this late date- I absolutely don't.

So it sounds like under normal circumstances the unit icon is sufficient. Are there currently any mods that don't use unit radar icons for distant units? What about the star wars mod?

Maybe it could be made a springsettings advanced option (use sprites for distant objects). Then we could directly compare framerates and render quality with and without fartextures. Changing the unit lod slider probably changes mipmap distances as well right? So changing the slider wouldn't give you an accurate comparison?

I'm actually quite impressed by the concept, it's very clever, but it's possibly optimisation overkill for modern GPU's and doubly so if it's rarely actually seen or used by mods.

For novelty I'd like to save the fartexture atlas to a file. It could be useful for generating bulk buildpics and icons. I could probably even hook it up to lua so mods could render unit and feature sprites on the fly (like for unit detail panels). Not exactly an essential thing but kinda cool I think. Maybe there's a function or lua script already, i haven't looked. I'm just thinking:

gl.RenderUnit(unitDefID, direction, size)
gl.RenderFeature(featureDefID, direction, size)


Anyway, I'm derailing my own thread because it isn't important now. Basic S3O type texturing is almost working. Currently I'm getting some strange results (like the whole unit rendered in teamcolor) but we're very close. I understand how teamcolor is defined in s3o and internally so that isn't the issue, it's just my code not working as expected. Will be fixing it later today (if BD hasn't already).

Plan at the moment is render the textures and material properties exactly as defined in the model, then add support for specifying an additional external grayscale or b&w texture for the teamcolor in the unit lua. We may also support the primary texture alpha channel for cutting holes in faces. I'll look into shaders later but not promising anything right now. Lua shaders should still work anyway.

I have no idea when (or even if) this will make it into mainline spring. It will need a lot of testing to ensure it doesn't cause desyncs or destabilise Spring. It needs to build cleanly on different platforms. Like always it will be ready when it's ready.

Thanks for all the help so far.

You didn't address Saktoth's concern about piece hierarchies. How will these be defined?