Spring RTS Engine

Parallax is not free, nothing is ever free, obviously some piece of hardware is running parallax and waiting for something else to finish and doing nothing.

Thus its important you recognize why, so as to optimize what IS causing the bottleneck, and to understand why, in order to take advantage of it. Simply calling it free is ignorant =/

Parallax Mapping is for free compared to just Normal Mapping, Relief Mapping is costly
(read the link trepan posted ...)

Why do these shaders actually need to be synced code? These are pure visual effects. Can't they be run as widget? As gadget there seams to be no reasonable way to shut it down only for one player. Something on/off-able would be nice here to give players the chance to save some fps.

I have checked the gadget on multiple computers and it causes a fps drop of 5-35% depending on how many units are on screen and on the hardware (using .png as normal map causes a drop of about 99% fps btw. ). While we have a nice grafical effect in close-ups the normal mapping is barely visibile at average playing distance. Thus it would be great to have the option to switch the shader on and off. Is that possible somehow?

It isn't synced => gadget != synced

It's just so only gadgets (an unsynced part of those!) have access to the luaUnitRendering system, you still can decide per computer if you want to deactivate it.

(hmmm, those screenshots give the impression that there's something wrong with the suncolors in the shaders o_O)

There's a widget version of it in PURE

Anyone using DXT5 may want to think about moving the red channel into the alpha and adjust the shader accordingly. http://www.gamasutra.com/features/20051 ... d_01.shtml


jK: I think it takes the color information for the light source from the map file

It does; the ambient and diffuse unit sun colors.

The widget version has several disadvantages since it doesn't use the UR interface (and is just old and slightly broken), I don't recommend hacking that one.

I am almost done with the Fresnel version btw. New release of this in a day or two.

Argh wrote:I am almost done with the Fresnel version btw. New release of this in a day or two.

Make it easily on/off-able!

Yes it should be LOD based ie it doesn't show unless at certain close-up distance... or something.

I apologize for the low resolution on the test texture, but I am fairly sure that most will understand what this screenshot means. I'll make something more suitable in a bit, now that I've finally sorted out the z-buffer issues.

This would work perfectly... if it wasn't for the borked Unit shadowmap handling not taking tex2 alpha levels into account properly. Grumble, grumble.

Just in case you're not sure what I'm bellyaching about:

No shadows:


Shadows:

Because transparent objects pass a shadowmap value of 0, instead of 1.0 - alpha, they're making things behind them shadowed far more than they should be.

these semitransparent meshes look tasty!

Combine this with mesh deformation, and we all can enter some very new territory in spring based games!

The "transparent mesh" is all just part of the same shader- normalmap, glow, teamcolor, translucency, reflectionmap, specular control. One shader, all behaviors. I have no real solution for self-shadowing problems other than applying a glow, but that's actually turned out to be sufficient (with judicious use of fakery).

I finally figured out why things didn't seem to come out right, specular-wise. Makes a noticable difference in terms of final behavior of the shader:





It's funny- this improvement was brought about by dropping the redundant specularMap and making a minor change to one line of code. I'm stupid and I didn't previously look at that little issue- the specularMap apparently just holds the fake sun / corona position, it's totally un-necessary even on maps without a cubemap background (and on them, it's doubly un-necessary).

I think that frees up enough varying-vars that I can put parallax back into the "crappy" version of this shader. We shall see, after I take a nap.

yeah shadows got a big fuck in the ass, not only are there issues with the lack of support for alpha they also "flicker" on both my pc and laptop when looking at more vertical surfaces.

Support for transparent faces is epic win...
It actually also might fix the bad situation for weapon projectile FXs (as currently only models are actually moved fluidly with the projectile's position). With support for transparent faces you know can fake stuff by e.g. putting two quads upon each other in an orthogonal way and have whatever "sprite" you want for your projectile...

Is that possible or does all this have to be initialized and works just for units?

Can these effects be used to create crystal or ice maps that will actually look reflective?

not only are there issues with the lack of support for alpha they also "flicker" on both my pc and laptop when looking at more vertical surfaces.

There are more serious problems. The shadowmap projections aren't being done correctly, and result in "floating" and self-shadowing, amongst other issues. The self-shadowing causes the flickers, but it's not the worst of the issue.

With the shader, I cut down the self-shadowing somewhat, but it still has to take the result from the shadowmap, so gross errors aren't avoidable.

I avoid taking screenshots where that's happening, but when you free the camera from OTA POV, it's obvious how borked they are. With the shader, it's better, basically, but not perfect.

I have a feeling that Kloot / jK have fixed the worst of it, to deal with Behirith's new code, but I haven't been able to pin down how to fix basic alpha transparency at the on/off level- I think it's just a missing texture reference and a line of ARB code, but I may well be wrong.

Can these effects be used to create crystal or ice maps that will actually look reflective?

No. That's going to require taking Behirith's modification of SM2, getting the resulting mesh's TBN matrix, and providing for a second texture and some GLSL that can render it in a new way, of which your idea is just one. It basically requires a new map format.

I can't do anything there, other than badger people and try to explain why it's well-worth the work. I suspect most of that's copy-pasta work, as MapConv already takes in multiple textures, the map format uses multiple textures, etc. But in the end it's really up to the engine programmers to see the possibilities inherent in having shader support as part of the map format. I can't even alter the current ARB shaders to do simplified versions, because all of the incoming variables are hard-coded and I can't play with the textures except in the crudest ways (i.e., I could make maps look really ugly, but I don't think people would appreciate it, heh).

However, it should be possible to make normalmaps that operate on ground splats... if there's a way to get the TBN matrix, which I don't think there is ATM (Kloot hasn't exposed that to Lua and arbitrary display lists, IIRC, it's just available through UnitRendering).

There might be a way to do it with some fakery, though, using a "unit" where it's really just a grid of quads and it uses the old zxswg stunt with moving verts. I'll look into that. That might allow for decals that can be quite large and look good- amongst other things, they wouldn't have to take up room on the !@*#*!*! textureAtlas.

soooo, what is the status on this?

Great work Argh

It seems to work nice on my old 7600 gt/linux/lastest nvidia drivers

Some errors/warnings does appears nevertheless, when launching spring in console.
I hope that it helps