smoth's junk.

[LordMuffe]

I don´t get that, why would they have to look like they have been in service for quite some time? i f the unit hasn´t been in a battle, why would it be scratched? I mean, the dirt part isn´t the problem, but dents and scratches?

Normally, before a military-vehicle is send to a mission, it gets a complete overhaul. And that includes the damaged armor and camouflage-varnish. They pretty much look like the day they were build.

And its the future, things have to look shiny

Anyway, they look amazing the way they are.

[Forboding Angel]

Scratches and dents? No thanks. It just rolled out of a factory 10 seconds ago and it's supposed to look like crap from the outset? If I get a crappy looking one will it cost me less minerals?

We don't want old and busted... We want the new hotness!

[9heart]

well

I agree for the most part

since unit materials are programmable now

Code: Select all

if (UnitHealth < 50%)
display Fugly

[smoth]

Unit health has to be polled. So if unithealth would require polling. I could possibly add some code to store unit health on damage/heal then query that table when I am doing the unit material pass.

Games are funny in that you have these cycles and each cycle information has to be checked. This is at a cost. HOWEVER, I do not see an issue with adding noise outside of 1 primary concern. Shaders have an expense, so for each texture look up they get more expensive. Currently the unit utilizes 4 textures + whatever optional texture is used for channels on texture 3. So there is a potential already for 6 textures, adding a 7th may hurt performance and I am unsure.

so it isn't as simple as you state. I have to weigh the pros and cons of doing this at a shader level.

Then there is the question of aesthetics. so I was shot by a few bullets, why is my units all burnt looking? why is my unit damaged when the weapon only hit the front? A general noise texture showing damage makes little sense, if this was a fps even then few of them do proper damage decals. So saying, well since you have a shader system, doesn't really cut the mustard.

One of the things I used to do was a noise pass after I finished the texture.

(click image for larger)
Which helps. However, when you are talking about a 30-40 foot machine, you are talking barely visible unless there is major damage or neglect. Something most military machines do not have.

If you look closely at this drill, the texture does have wear:


I will likely add a bit more wear to the texture as time goes on but nothing like the asinine rustbuckets you see in many games.

Shaders are not magic, there is a cost for everything I do. I may add a detail texture in the future to add further noise but likely that I will just add the noise to the base texture. This is a conversation I have had many times with different people, each time I grow more weary of having it. Real military weapons ARE maintained.

Thanks for the feedback and all, I do appreciate the interest and if you would like we can talk about it a bit further but only to a point, I don't want to fill my thread with this discussion. I am just trying to give you some feedback on your input.

[jK]

Games are funny in that you have these cycles and each cycle information has to be checked. This is at a cost. HOWEVER, I do not see an issue with adding noise outside of 1 primary concern. Shaders have an expense, so for each texture look up they get more expensive. Currently the unit utilizes 4 textures + whatever optional texture is used for channels on texture 3. So there is a potential already for 6 textures, adding a 7th may hurt performance and I am unsure.

1. tex1
2. tex2
3. specular cubemap
4. reflection cubemap
5. shadow
6. ?

[smoth]

Shadow, spec and spec are not unique to my materials stuff are you assuming based on what spring already uses rather than my own?

[jK]

Yes, when you added 4 additional to those 6 (6th would be normalmap), then u are really at the upper end of what is advised. I wouldn't go over 12 texture fetches, still models `normally` cover less than 10% of the screen, so pixel shader cost is limited.

<3~6 := for-free (shader overhead is bigger than texture fetch latency)
>10~12 := noticeable performance drop (in case of many drawn pixels)

[smoth]

Is that true for lower end or is it somehow one of those general rules?

[Floris]

Smoth, what happened to choice?
You know.... an opt-in or opt-out for this wear effect/shader/tex?

... or is it maybe so that you're simply not fond of spending time on this effect, because you dont like the idea of scratched new units yourself?

... so instead the discussion went toward the horrible horrible exponential collapsing terminating performance issue it will bring. )


I really like BAR's wear on units. Robots aren't like shiny new smartphones, cars or meant to be jewelry anyway. They are functionality over form, and could accentuate this just fine with some wear!


One more thing....the adding of scratches on heath decrease could be nice, but removing scratches on healing might look a bit odd

[smoth]

To answer your question earlier jk

1. tex1
2. tex2
3. specular cubemap
4. reflection cubemap
5. shadow
6. bucket texture
7. normals texture
8. red projection texture
9. blue projection texture

If my understanding is correct.

Smoth, what happened to choice?

There is a fully working scheme system, I showed it in the video. I am not sure what CHOICE you feel I have taken away, I have been exceptionally transparent this entire time posting videos explaining how the whole thing works.

You know.... an opt-in or opt-out for this wear effect/shader/tex?

opt-in or opt-out? Where did I EVER say players could choose to not use the shader? Without it, much of the models would be grey. What effects did I promise? I am not sure you understand what this is and what it does and does not do.

... or is it maybe so that you're simply not fond of spending time on this effect, because you dont like the idea of scratched new units yourself?

... so instead the discussion went toward the horrible horrible exponential collapsing terminating performance issue it will bring. )

Nope. I am mildly offended that you essentially want to accuse me of laziness. Futhermore, my project, I can do it in an art style I find attractive, who are you to tell me otherwise?

I really like BAR's wear on units. Robots aren't like shiny new smartphones, cars or meant to be jewelry anyway. They are functionality over form, and could accentuate this just fine with some wear!

Um, dude, I spent months designing and redesigning how the shoulders would work on these units and how I would try and present different points of articulation. Bar does not have that, I sat down and actually tried to imagine how the thing would move. As far as bars wear on units, I was the one who went in and tweaked the specular and reflective levels to bring out the unit wear and tear. What bar has is actual TEXTURE for the wear, wear which would be anywhere from 1-2meters in width which is exceptionally unmaintained and really barely would make sense even on a TRANSFORMER which lived for >1k years(they have in some of the story lines)

One more thing....the adding of scratches on heath decrease could be nice, but removing scratches on healing might look a bit odd

I'd rather have electricty or some other effect to represent a unit in critical state

[Floris]

I shouldn't have responded here. I see my tone might be too negativly interpreted, but I meant to question genuinely, and was misunderstood. I'm sorry.

[dansan]

I think there could be a difference between hero units like Gundams that imo have to be "shiny", and "off-the-shelf bots" for "your common mass battles". I don't know if you have those, though. Also tanks tend to get dirty quicker that bots (except for the "feet").
From what I see the units are not shiny, but have a mutt/dull surface - which I find most attractive!

[AF]

The units in smoths game aren't manufactured they're assembled from second hand parts

There you go, problem solved, wear and tear AOK

If you're still unhappy:

- They were warped in protoss style from a distant battlefield that had been won and are actually veterans not freshly built
- They were warped in straight from the factory and suffered wear and tear along the way
- They were assembled from nanobots but nobody has a template for what they're supposed to be like aside from some worn originals with obvious fixes
- The people have a cultural fascination and deliberatley add wear and tear for aesthetic reasons to show off fighting prowess
- Machines are deliberatley made to look as if they're worn so the enemy can't tell if they actually are
- Factory workers in this universe are incredibly clumsy

I'm sure Smoth can think of an ingame explanation if none of mine are satisfactory without relying on modeller/texturers personal preference

[Beherith]

Wreck texture in customunitshaders:

[smoth]

Not sure I can affor another texture call is my count correct jk/ behe? Also must units would be drab but I have reflective control because I can :)

[zwzsg]

I love the concept of having the unit texture or model degrade with damage received, in such a way that you can tell its health without looking at health bars or figures.

But I agree it would be difficult to pull out well.

Not only from the technical point of view, but from the artistic one: Making a damaged look that still look good from afar, leave the unit recognizable, has many thresholds of degradation, and doesn't increase the asset production workflow too much may be challenging.

[Beherith]

That wreck modulation texture is generated with World machine from the basic tex1 and tex2 images. It is a single channel image tucked into the alpha channel of the normal map, so it does not require an extra texture lookup, but it does require a uniform to be set in the custom unit shader to govern effect strength.

[smoth]

@Behe:
oh, cool, I did not think of utilizing the alpha channel of the normal map to store it! Do you think my count of the current texture look ups is correct or incorrect?

@zwzsg:
Yeah, that is my concern, before I go and implement something like this, I would rather like to find a better way of representing it. Currently, I cannot figure out a good way to represent damage on a unit. I mean, I know in other projects, this sort of unit-wide damage may be ok, but I have yet to figure out a good way. Also, I prefer health bars over damage textures, if that unit is alone how do you really notice the difference? it should spark etc. However, all these effects and things are an extra performance hit which I am reluctant to add. Then again, I was apprehensive about gonig for this materials stuff, was worried it would be a lot of effort to only find out it was beyond my reach. OF COURSE, HERE, WE, ARE, it works.. so who knows.

@Dan
There are a series of "schemes" available, there are the standard schemes and a local scheme stored for each player called "default." If you change "default," you can do this ALL DAY but you are the only one who will see the change and it will ONLY effect your units.

I had thought about establishing a way to have a player's scheme copied into a local dir once a player joins. That way, the more you play, the more schemes you have, assuming people would use this. There are a bunch of reasons this would be VERY cool but I don't want to spend the time to compliment such a thing. So at the moment, only the schemes that are preloaded would be available. I may make it possible to save your local default scheme and scheme settings, loading that where available. However, at the moment, I just don't want to do the work.

Mostly I added the control over the reflective because I already have reflective and specular so I wanted to add more control to it. I still have to add it to the ui and build it in the code. at the moment, it piggybacks on the shinny setting.

@AF:
I am not doing that as my established story. I am probably going with something different from any other spring project as far as unit production.

Wear, dirt etc:
I have had this discussion before:

Because the spring quotebox is has odd vertical scrollbars right now:
Me: Sun Jan 27, 2013 9:04 am

I know not everyone favours that gritty battleworren look... but.. those are mechanical parts at your feet, and beeing constantly around sand, dirt and abbrassive material in general should wear them down..

yawn, this again.

IRL scratches from sand are very small in comparison to the size of the unit. Unless there is massive neglect, we are talking left outside, and repeatedly slammed into one another there would not be any visible wear at this texture scale. I am pretty sure I have been over this.


mostly what you would see is the sand and dirt forming a sort of film on the unit.

There are scratches but at a distance they become visually non-existant


in a moist environment tanks may show rust and scratches more visibly but it is dependent on the environment and what they were driving through


Of course that would require an alternate dirt application based on the map and either a new channel or yet ANOTHER texture for shader passes to be assigned to the correct areas.

Not that you actually ever payed attention but I did do dirty on ace units in GRTS:

(click for larger)
No one ever really looks before they talk

all those micro scratches on such a large scale merely give dirt a place to rest, so dirt accumulates. However it is my belief that the pilots and crews who would maintain a mech at least clean their machine.

So there is your answer, I am tired to replying to the "rust it up unrealistically" requests.

[dansan]

Idea dump
If each scheme has an ID, all players could broadcast their chosen scheme with a luamsg to all others, so everyone could see the others as they see them selfs (I assume the opponents units atm get all painted to scheme "default", and that this can be changed by some wi/gadget that reacts to said luamsg).

IDs for schemes (incl. custom) could be a unique hash over the serialized description of the scheme. If a schemeID is unknown to a player, that serialization could also be requested and transmitted via luamsg.

I haven't thought about security implications of this. One thing that comes to mind is, that a player could camouflage his units with the same scheme the opponent uses.... actually that would be cool But the counter is easy: a widget that detects same/similar schemes could mark those units as opponent again... maybe that ga/widget would be activated only by installing an addon on your unit(s) / radar facility...

The idea of the "rotating shield frequency" translated would be that if two players use the exact same theme, one would make small random changes to some value, and if some other player does the exact same change (both following the luamsg about scheme changes during game play), then a camouflage would have be detected.

omg... sorry... some part of my brain switched unnoticed to my consciousness some scifi-synapses on and my fingers just kept typing...

[smoth]

Not sure if this will clarify things are they are or not

Overview

• Each scheme has an id.
• Each player has a scheme id
• Each player can set any scheme.
• Each player has team colored health bars and platters.

Lexicon:

• Default scheme: a local scheme you can change and only you will see the changes of.
• Bucket settings: settings that effect texture3, the bucket texture.

General explanation
So if you start the game. You have the "default scheme" assigned. I called it default because "local scheme" or "player side scheme" would confuse the average user. Say you choose a different scheme. You cannot modify this scheme, every player can have any scheme(currently). The widget does communicate to a synced gadget the player's color scheme selection. I need to move scheme choice to the player param or whatever, but this was written before then and it is a minor thing.


Each player but myself has the jimbob scheme. I am still using the default

Team colored health bars and platters prevent one player masquerading as another. These are the lobby assigned colors. Hopefully, this will alleviate the frustration of having a color you don't like set by the auto host. the auto setting of colors via auto host will also change these. Any color changing stuff like the ally enemy colors will effect the platters and health bars.


all players are using the jimbob scheme.