Spring RTS Engine

Guys, all this backbiting isn't helping anything at all.

Seriously.. If I was some new guy walking in on this game hoping to learn something, I'd shit my pants and run away.

Said my piece, now I'll just stay out of this.

If I was some new guy walking in on this game hoping to learn something, I'd shit my pants and run away.

QFT. This needs to stop, people.

It's awful enough for art newbies around here, when they invariably try to model something from OTA or a <gasp> random tank, and somebody tears them apart.

But this kind of stuff would convince anybody with half a brain that we're all complete asshats around here. The sad part is that it's true, we are asshats, not just one or two of us, but the majority of the artists Must be something to do with the technical requirements... the Freelancer forums were never this bad, in terms of how artists would treat each other, but it was (relatively) easy to model for that game engine. I was by far the worst of the bunch, I will say, but was never as rude or as argumentative as I find myself being here.

I don't have a magic cure for this, but I am really getting tired of it. I think that we need to quit treating every issue involving Art like it's a debate, and people need to leave other people's work out of threads about general topics, unless critique is asked for. It's just incredibly lame that we cannot even talk about something this general, that has many solutions, without people getting really personal and rude...

art is more then some bland subject and if you are not passionate about it then you are missing something. Forb, I wasn't being a dick, there were very valid points that made up 99% of my post. Argh just, as always finds one or two negative things in the post and centers around them to distort the discussion. He then attacked me as a person rather then even bother to argue the issues. THAT is ad hominem. I actually was discussing the subject at hand. Argh normally does this, he burries it all in bullshit then pisses someone off then cries victim. he did it with fangs tank, did it with me in gundam.

I dropped it last night after I realized that argh was using his standard argument tactic of burry the actual discussion in bullshit and pretend that I never had any actual point. Good job.

Argh wrote: and people need to leave other people's work out of threads about general topics, unless critique is asked for. It's just incredibly lame that we cannot even talk about something this general, that has many solutions, without people getting really personal and rude...

oh wow, does this mean that you are going to respect others now?

Warlord Zsinj wrote: You both need to act like the bastions of the community that you clearly are.

not in disagreament but last night before argh made it about me, I was debating the point. I actually did hold back in my post, argh over focused on what he felt was grievous insults. Argh uses that age old netizen tactic of once he has failed to present valid points he will derail discussion and then come back in some other thread later and post those same points. If someone doesn't correct him, then people see it as actual truth because argh presents it in a way that can only imply it's factuality.

I would rather not see such foolishness take hold. Argh is good at rusting stuff up and making it look really weathered but time and time again he does not do the team color correct. You know this as well as I do. However, because he fails to properly utilize the spring team color system he declares it useless or no good.

Warlord Zsinj wrote: Also, don't knock colourblind people - I'm partially colourblind, and I have to have gnome tell me from time to time when I've missed colours entirely

Not trying to at least I don't think I did. My only issue with colorblind things that that I am huge about colors and if a color is off, that bothers me. The red is not pink thing wasn't about colorblind it was about argh have a propensity to always believe himself the expert on all subjects.

The reason I get pushy about teamcolors getting muted is because if I wanted my team muted I will mute them. Premuting a color does change the resulting color. For those of us like myself who use specific colors or try and make interesting colors past your standard ota colors it is annoying. Most of the starwars units are not so bad in this respect but some of them are. However, I find I am the exception and not the rule, which is why I was saying in that thread that I do not expect you to go that direction.

Well smoth, you did in that post, essentially say that Argh was the following:

1. Not competent at photoshop

2. Awful Texturer

3. An Ignorant Moron

So Id have to say he does have somewhat of a valid point in being offended by such statements. I personally would have recommended attacking the issue from a more technical stance rather than just saying he cant do teamcolor properly. Which while possible true, is also an insult and not really a reason. Perhaps an explaination of how he does teamcolor improperly on a technical level would have been better suited.

on the same hand if argh really was offended he could have pmed me about it. Rather then muck up the whole thread. He then could have used the thread to discuss the issue at hand. Also, I don't think I said anything about his photoshop skills,.I don't think he uses photoshop, being the self appointed champion of legal issues, I would presume he uses something he bought.

I was just poking fun about the colourblind thing. I am actually colourblind, but I don't really care.

I do think Argh can infuriate people with a tone that can be misconstrued as 'haughty' or 'holier then thou' - I don't think it is intended, but it can be dangerous in an art forum where ego's are allowed to run free ( ). I think what you were saying, however, had plenty of valid points (that is, your topic-related argument), but these got lost when you started trashing Argh's work, which wasn't necessary.

Let's take this thing back on topic, shall we?

The reason I get pushy about teamcolors getting muted is because if I wanted my team muted I will mute them. Premuting a color does change the resulting color. For those of us like myself who use specific colors or try and make interesting colors past your standard ota colors it is annoying. Most of the starwars units are not so bad in this respect but some of them are. However, I find I am the exception and not the rule, which is why I was saying in that thread that I do not expect you to go that direction.

I'm not sure if I 100% agree with this line of thought. I agree with you that team colour is essential for gameplay reasons. Where I diverge is perhaps in what I think the player should and shouldn't be allowed to do. This borders on a gameplay discussion, but as much as I am for emergent gameplay through variable options for players, I also think that as a good designer (be it art or gameplay), you must still 'craft' what your user sees, does, and can choose to do. That means opening some roads, giving them forking roads in some areas, and blocking other roads so that they experience what you want them to experience. Being able to define your own experience is importance, but as designers we must create the bounds in which these experience can exist; else that experience be missed or diluted.
I'm going somewhere with this, I swear...

I am not a big fan of the fact that players can muck around with their teamcolour a whole lot, and access the entirety of colour pallette for their units. By all means give them a wide range of colours to choose from; but this must be controlled within bounds. This is because for me, the players choice of teamcolour is there to
1) be a colour which can be differentiated from other colours easily (which is another reason why a full colour palette option is bad)
A distant 2) Be a colour they like

I note that 'making the units look good' does not fall into those options. The player should not have to choose a hue that makes his units look good - that's my job.

To bring it back to my original point, I am crafting the experience for my players. In my mod, this means creating a gritty war environment for immersion, and creating a gameplay environment where two players can differentiate their units with ease (not necessarily in that order).

Both of these rely on my input as the artistic designer. I decide how bright or dark teamcolour should be, because it is my job to make sure that my players experience the immersive quality of the mod, as well as have the ability to tell their units from their allies/opponents. It bothers me that currently the player has far more control over that, and can deaden colours well beyond what I would like.
Seeing as there is not much I can do there; I design for the default colours, because the vast majority of players select from them, so I can provide for the largest amount of my audience.

Red vs. Pink


Home sweet Home on Fire. You know you are reading the springboard when a red colour and a pink create a Fireball.


Red vs. Pink!

well, then if I recall correctly you can actually control colors via lua and that might be an option.

An ingame option to override and color enemies red and friendlies green would be better then forced teamcolors.

How about enemies => shades of yellow, orange to red, own team green or blue, allies light blue or light green.

There was that fixed team colors widget from trepan IIRC.

I'd imagine there would be different tastes, altough for a simple competitive 1v1 I'd bet everyone would want something simple with maximal clarity, my stuff = bright green, his stuff bright red.

a neat mod option would be force TA colors, where players are forced to do the TA pallete. That would be cool, I wonder how it would work out.

smoth wrote:
1. It is ok, we cannot all be competent in photoshop.

3. Only if you are a moron, that was a good video, I added it to my research playlist when zpock posted it.

2/3. texturing is aweful and setting a unit color to something that is pleasing is part of our aesthetic sense? Honestly, if I wasn't doing something with true canonical colors I would dazzle you out of your ignorance.

Not trying to be an asshole here smoth, just pointing out you did call his competence with photoshop in to question regardless of whether he uses it or not.. Case in point you are correct, he should not have sunk to a level of continued personal attacks if he was in fact offended. He should have instead won the argument through evidence which would further put him in the right..

However It would be better to make a more defensible position next time smoth, so that you in fact cannot be called out as wrong yourself. This further enhances the points..

Zpock: Wonderful video! Exactly what im talking about. TF2 has made a deliberate decision to incorporate unit and side differentiation (note they also talk about the different units, not just about team colour!). Yes it was done in an animated, exaggerated style- but i think its possible with quasi-realism, especially in a sci-fi setting. A robot with the proportions of the Heavy or the Scout would look fine.

Again, this applies less to those using established fiction (I think thats merely unfortunate, rather than desirable), but its one of the driving philosophies behind the new CA art direction.

http://media.moddb.com/images/mods/1/6/ ... een156.jpg

This screen really shows the muted baby-blue teamcolour, which is, i assume, the default blue? See, thats not what it looks like in the colour picker at all. Its saturation here is incredibly low. Googling up a picture of an x-wing shows much higher saturation on the painted bands so it isnt the fiction limiting you here. Some of the background colour is even showing through. On the redder vehicle, the blue has a reddish tint. Id strongly suggest taking your alpha channel, and using it to darken all the teamcolour areas, so they dont get baby-bluerized.

I dont mean to pick on your mod or art, again, but you keep using it as an example....

Maybe I should use a small, teamcolored marker next to the healthbar (although that would probably conflict with the Healthbar Widget).

Include it in your own healthbar widget, or put it outside the area the healthbar widget takes up (in the same way the rank icons widget works). AFAIK there are people working on this already perhaps they'd share it.

No team colour on the unit + teamcolour platter widget = solution.

A bright teamcolour will contrast too much with the unit, washing out the detail on the unit itself. Ive tried Xray shader, glow etc widgets and they all have this problem- they increase team recognition at the sacrifice of unit-to-unit recognition.

As for forcing players to pick only certain colours- I personally have no trouble with a player being able to pick any colour he likes. If a player picks a colour the others are not comfortable with, visibility-wise, they can always ask him to pick another. But IMO, there is no reason you cant make your unit look good with any colour.

On the fixed teamcolour thing- green is a bad colour, too many maps are green. Red vs blue is better, but even then, there are lava/mars and water maps.

P.S ignore the flames and they will go away.

How does teamcolor actually work?

Spring uses an overlay approach to rendering teamcolor. The alpha channel of texture1 is the value of the overlay, when rendered. Therefore, a value of 255 will render the pure team color, minus any change due to the angle of the normal when lit.

Anything in between, you will end up with something less than 255 before the lighting calculation takes place.

This creates some challenges. For example, if you have a pure white area of teamcolor "painted" over an area of the model that has strong contrasts, the high alpha value of the overlay overdraws the underlying texture1 completely, and they will not be seen. Care has to be taken to draw this texture carefully and use the alpha values wisely.

Teamcolor, normal RGB, with alpha less than 255

If you use, say, a value of 128,128,128 gray for your teamcolor, it will now show some of the texture underneath. This results in a very "faded" look.

It doesn't actually look much like paint, but you can see some details beneath, so you don't have to re-create your details again in grayscale. This is how most games in Spring are implementing teamcolor, and used in large swatches, it gives the unit a strongly teamcolored appearance.

This can look good, but it has some major disadvantages, both aesthetic and technical:

1. If you use this method, your models will appear to be mainly teamcolor, from a distance, or they will not have any teamcolor at all, depending on the size of the swatches used. This is because as you get farther and farther away, mipmaps and the fragments combine to reduce the overall size of the teamcolor, along with everything else, and the value changes produced by Spring's lighting model may obscure the hue of the teamcolor significantly. Therefore, to make this approach really work well, it's all about percentage of the model covered- somewhere between 20-50% of the upper surfaces probably need to be covered, to get a good result. For games trying to have a realistic feel, this may not be appropriate.

2. From a technical standpoint, because you're almost never going to see values of 255, in practice, your teamcolor as displayed to the user is going to be quite a bit darker than the pure color that the player chose. And, if players use dark colors, they will end up with teamcolor that is nearly black on most surfaces, after lighting calculations occur.

Teamcolor, RGB 0,0,0, any alpha

Teamcolor with a background of 0,0,0 is whatever value of gray that the alpha channel uses. This produces a very pure set of colors, with a strong, painted look.

However, this comes with some significant disadvantages. Because this is not really making use of texture1, it looks really unrealistic, when compared to textures elsewhere on a model, that have been weathered. If you're not weathering your models, this isn't a problem, of course.

You could mix-and-match, with the first approach, of course, but that would be a lot of work, for relatively minor gain, imo.

Teamcolor, RGB any value, any alpha, plus glowmap

Teamcolor and the red channel of texture 2 interact, because it is rendered on a pass after the teamcolor. The red channel is treated as an 8-bit grayscale, and it uses an overlay rendered without lighting during its rendering pass, to change the value of the texels.

Basically, in this method, teamcolor is treated as a special type of "light", which "emits" a glowing source.

I think this method has a lot of promise, for delivering teamcolor that is accurate to what the user chose, and covers a model widely enough to be instantly recognizable at a distance. It would be better yet, if Spring supported multiple light sources within the main rendering pipeline- then I could just use teamcolored lights to achieve this look, and it would be accurate to Piece positions, which is the primary problem one encounters, when one is dealing with "lights" that are purely on the texture itself.

An example of this method being used can be seen here:



Having tested this a bit, I think the main question is whether or not I want to take the time to rig up AO settings and distortion maps at some point, for completely accurate rendering of the "light", or just airbrush it out, which is a lot faster and will probably look about as good in most practical circumstances.



At any rate... to sum up, it's not that I'm not quite aware of how things work. It's mainly about what I want things to feel like, which is an aesthetic decision, and purely personal.

I thought team color gets blended using it's own alpha value for translucency. A lot of other games use the exact same method (including CNC3 for example).

The only thing I find difficult about this is bringing in highlights and shadows into the team color, as you need to draw the highlights onto the texture while subtract shadows and highlights from the alpha channel (like accurately subtract them). Stronger team color doesn't count.

It's definitely not impossible but can be annoying sometimes, at least it's annoying me. Actually only the highlights are.

Anyway, a layer of 127 gray in Pin Light blend mode (or however it's called) on full black works pretty nice, as it ignores anything up to RGB 127 and then blends it in at half the strength while you can still use dodge and burn tools on your gray layer for highlights, scratches or what ever else. In Photoshop that is.

That fuglycopter was my last attempt at getting anything done with this in mind (yeah wasn't the first attempt) and it worked nicely in the end, IMO.


Of course there are other ways to do this, looking at Gundam etc.

I thought team color gets blended using it's own alpha value for translucency. A lot of other games use the exact same method (including CNC3 for example).

It's not translucency, it's gl.Blending, IIRC. It does a blending pass over each texel. This is part of the reason why teamcolor seems to abruptly disappear with distance, if there isn't enough of it- the texels simply don't include the teamcolor pixels any more That's why I'm playing around with this "lighting" method- there will be pixels of teamcolor on just about every texel of the upper surfaces, yet it won't be overpowering, if executed well.

Gundam just uses teamcolor as an 8-bit texture, pretty much. That's great, for something with a cartoon look, but I don't think it's appropriate if you're trying to achieve realism- then you pretty much are stuck with a value 128,128,128 over texture1 + editing, or you're going to have to do something else... I'm still trying to figure out the "something else", because I wasn't happy with the standard "paint job" approach, it looks terrible on the monochromatic Overmind units, completely destroying their look.

Argh wrote: Gundam just uses teamcolor as an 8-bit texture, pretty much. That's great, for something with a cartoon look, but I don't think it's appropriate if you're trying to achieve realism- then you pretty much are stuck with a value 128,128,128 over texture1 + editing, or you're going to have to do something else... I'm still trying to figure out the "something else", because I wasn't happy with the standard "paint job" approach, it looks terrible on the monochromatic Overmind units, completely destroying their look.

argh, all things are using 8 bits per color. RGB is used for all standard image formats. You have to go up to 16 bits per color to go past rgb. I am really busy and do not have the time to further explain this but ALL IMAGES use 8 bits for color.

a 32 bit image uses it's bits for:

8 bit red
8 bit green
8 bit blue
8 bit alpha.

I am sorry but no. 8 bits = 0 - 255. it is simple binary. And in case you want to further argue: "There are 2^8 (256) possible values for 8 bits.(in binary)"


also, team color DOES NOT use an additive blend, it uses an overlay.

smoth wrote:

Argh wrote: Teamcolor is very un-subtle, though, and it's very hard to get it to come out really nice, in my opinion.

I whole heartedly dissagrea:



Teamcolors can just as easily replace the panel in full range. I was using the default blue and red I also could have lightening these up but meh, just wanted to show team colors can infact make the full range on a texture.

say a stripe of color even, I would be very happy with that, like a single stripe on one of the wings of your aircraft. these are just suggestions but I do find the team colors more then accommodating.

also from a previous post, these are entirely team color.

Argh wrote:How does teamcolor actually work?

Teamcolor uses an additive process during a rendering pass, altering the RGB values of the fragment's texture1 texel by adding value 1 (RGB, texture1) to value 2 (RGB, texture2).

Did you not bother to test this, or did you test it and actually manage to fail to see how it works? Look at simbase, everything is white, and team colour works just fine.