Various Rendering Crap

[Argh]

This S3O fragment program should result in alpha transparency using texture2.

!!ARBfp1.0
# S3O model rendering without shadows
#OPTION ARB_fog_linear;

TEMP temp,reflect,texColor,extraColor,specular;
TEMP tempColor,shadeColor;

#get unit texture
TEX texColor, fragment.texcoord[1], texture[0], 2D;
TEX extraColor, fragment.texcoord[1], texture[1], 2D;

#normalize surface normal
DP3 temp.x, fragment.texcoord[2], fragment.texcoord[2];
RSQ temp.x, temp.x;
MUL temp, fragment.texcoord[2], temp.x;

#calc reflection dir
DP3 reflect.x, temp, fragment.texcoord[3];
MUL reflect.x, reflect.x,{-2};
MAD reflect, temp, reflect.x, fragment.texcoord[3];

#get specular highlight and remove if in shadow
TEX specular, reflect, texture[4], CUBE;
MUL specular, specular, {4,4,4,1};
MUL specular, specular, extraColor.y;

TEX reflect, reflect, texture[3], CUBE;
LRP shadeColor, extraColor.y, reflect, fragment.color;
#LRP texColor, texColor.w, extraColor.w, texColor;

ADD shadeColor, shadeColor, extraColor.x;

MAD result.color, texColor, shadeColor, specular;
MUL result.color.w, extraColor.w, fragment.color.w;
END

It doesn't. What blending mode is being used, engine-side, that's forcing it to a threshold value (i.e., anything below 0.5 == 0, above == 1.0)?

I assume that this is because the resulting value's supposed to be used when rendering the shadowmap, which needs to be 1-bit?

So... is this going to get fixed, ever? Or should we assume that nobody can fix it to work like it used to, and we should write a custom shadowmap implementation in GLSL at some point?

What's the problem? Does anybody know? This used to work. The fragment programs haven't changed, and are still reporting clear pixels back when the fragment program terminates. So, what got broken, and why is it so terrifying to fix it?



While I'm thinking about the shadowmap stuff...

If map damage is disabled, then it should be possible to quit including the terrain mesh in the shadowmap generation step.

Then... voila, much cheaper shadows. Project them onto the terrain mesh and let mappers bake shadowmaps and lightmaps.

Then lighting is entirely irrelevant to maps... and we can quit lighting the terrain entirely and just render the fragments + Unit shadowmap, which would save a lot of CPU / GPU.

I know map damage is considered a "major feature" of the engine, but in truth it's been mainly turned off in most games, including BA, with only a few exceptions for giant nukes et al.

I see no reason why it cannot be supported as a legacy feature, but it's a performance dead-end.

Everywhere we turn, map damage gets in the way. Pathfinder? Gets borked by map damage- I repeated my old experiments with NanoBlobs again, and it still screws up pathfinder performance, royally.

LOS? Same. Can't assume that terrain's where it was, have to fetch it every time... slow.

Raw rendering of the terrain mesh? Oops, there again- we're lighting all of those triangles, and since we don't have dynamic suns... the only reason is... yup... map damage.

Gotta light those fragments, because otherwise the lighting might not match the mesh. Hey, guess what? If the triangles were fullbright other than Unit casting shadow volume shadows on it... it'd look the same, but it would render massively faster!

Can we please move beyond this issue, and get the featureset I'm requesting here?

This is a major hurdle in terms of performance that's really obnoxious. It's really crummy that we all have to eat the massive performance headaches for a feature that most of us aren't even using any more, and I don't use at all.

[Tobi]

glAlphaTest and GL_BLEND not enabled possibly?

For transparency it's fine that fragments are either visible or not visible, with nothing in between, that's, like, the definition of transparency.

Suppose you want translucency? (Technically needs all triangles to be sorted before rendering (huge slowdown), but maybe the artifacts are acceptable.)


Lighting with one light in hardware is pretty fast nowadays, don't think there will be a noticeable advantage to disabling it. (Should be easy to try tho, just comment out glEnable(GL_LIGHTING); at the right place, or change it to glDisable(GL_LIGHTING);, and then profile.)

[Argh]

Technically needs all triangles to be sorted before rendering (huge slowdown)

Meh. I can already do this via Lua just fine. I just found it irritating that I couldn't do it via the shader, was all.

Lighting with one light in hardware is pretty fast nowadays, don't think there will be a noticeable advantage to disabling it.

Yes... but look at the rest of the list. Moreover, it's not the lighting of a single fragment that's the issue. It's the requirement that these objects are part of the shadow volume system that's the real burden.

Turn map damage off, and all of a sudden, a bunch of options are available. I think that when they're all combined, they're going to result in very large cost savings.

Anyhow, I'll be happy to look at the code for this, but I have no idea if I'll have time to get the engine to compile again. However... I think that I could just rewrite the vertex / fragment programs, and try it out for myself. At the very least, I can then tell us what things look like, performance-wise, when it's fullbright. Even I am smart enough to write that.

I just disabled the detail texture, btw... and that resulted in a non-trivial performance increase, at least over here (no surprise there, that's a lot of fillrate). Gotta get some sleep now, I'll look at more things Sunday or Monday.

Been too damn busy with P.U.R.E. to really do a lot besides think about these things. The fragment program stuff's mainly redundant atm- between Kloot's stuff and other things, I think that drawing Units via GLSL is really the only viable future anyhow.

While I'm on this topic, though... can Lua make use of ARB fragment shaders?

I don't really *like* ARB, the lack of IF-->THEN makes me cry (if anybody knows the assembly equivalent, I'd love to hear what it is). But it seems like it's more compatible with more hardware than GLSL is, and I'd like to maybe experiment more with it.

Oh, and... wow, if I wasn't an idiot, I could have baked the shadows on my maps and done fullbright with shadows overlaying.

Seems that the shadow texture coordinates are all done in the vertex program, then returned to the CPU for more processing (which has gotta be ouch). That's it's own section... so easy come, easy go... later. Must sleep now.

[Tobi]

The map will need to be rendered on the shadow texture in any case, otherwise the map doesn't cast shadows on units / features. So the only thing you can save is one texture lookup and comparison for every fragment while rendering the map.

On what kind of card are you testing? It seems weird to me disabling detail texture gives a huge performance benefit. (Usually Spring doesn't even come close to being fillrate limited.)

Most things are only costly when map damage is actually being used (map damage doesn't have any impact on path finder or LOS if there is no map damage); removing any map changes altogether may allow for some nice optimizations here and there, but I think too much games already use e.g. terraforming to just remove this feature.

Of course by properly refactoring and abstracting stuff someone could "just" perform the same optimizations (e.g. write a new map renderer, LOS system, etc., that is optimized for 100% static map data) without removing the feature for games that want to use it.

[Argh]

The map will need to be rendered on the shadow texture in any case, otherwise the map doesn't cast shadows on units / features. So the only thing you can save is one texture lookup and comparison for every fragment while rendering the map.

I tried it, and it's not very noticeable unless you have severe heights involved.

But you're completely right- the performance increase is entirely minimal, and not worth bothering with. If you're going to run shadows, it's a significant performance hit whether or not any given geometry is actually seeing use, on the shader end. So any real optimizations of this would have to be engine-side.

On what kind of card are you testing? It seems weird to me disabling detail texture gives a huge performance benefit. (Usually Spring doesn't even come close to being fillrate limited.)

Testing on the good ol' 7800GS here. On World Builder scenes with a lot of Units being rendered on-screen, it's good for about 3-4FPS. Not a huge change. But I use a practically neutral detailmap anyhow, so I see very little reason not to improve the performance a bit.

Most things are only costly when map damage is actually being used (map damage doesn't have any impact on path finder or LOS if there is no map damage); removing any map changes altogether may allow for some nice optimizations here and there, but I think too much games already use e.g. terraforming to just remove this feature.

I don't want to remove it, I just think that it would be good to explore more options.

Of course by properly refactoring and abstracting stuff someone could "just" perform the same optimizations (e.g. write a new map renderer, LOS system, etc., that is optimized for 100% static map data) without removing the feature for games that want to use it.

Yeah. But the "just" isn't that bad, if you're correct and most of the executions are only happening if map damage occurs.

However, the issue with the tesselation not taking the camera's current vector into account is a bigger and more immediate savings. Can somebody please explain why this is so hard to fix? It just uses a vector that's basically 0,1,0 right now... why can't it just use the current camera vector, which is readily available in the engine and recomputed every un-synced cycle?

While I'm on this topic... shadows are still broken, and it's not the ARB fragment shader's fault. I've checked it and tweaked it, and while I actually came up with a great "bloom" effect and some other things, I am quite confident that the problem is on the engine end- I think it's just plain not handling updates correctly.

jK said he'd get to it if I didn't bug him... six months later, it's still broken, and has been for over a year now. What's going on with this? If I hunt for vertex-buffer shaders that will do this for a scene, can we finally modernize this feature of the engine?

And nobody has answered the ARB thing. Can I use it in the OpenGL pipeline via Lua?

I know it may seem bizarre that I want to play with something so antiquated, but meh, if I'm screwing around with Spring's shaders, it'd be nice to have ways to write experimental stuff that doesn't rely on Spring delivering variables / parameters...

[Tobi]

The map rendering code isn't particular easy to understand or modify IMO, that probably contributes to the (lack of) speed things in it get fixed

I don't know about the ARB thing. Maybe just try it?

[Kloot]

And nobody has answered the ARB thing. Can I use it in the OpenGL pipeline via Lua?

No.

[Argh]

Ah well.

BTW, dynamic water's so slow because it wants CPU updates all the time on the input side. It's reading a lot of CPU-side variables that it shouldn't be- all it really needs is the X,Z location of a new input and the amount of said event. Old events should proceed without reference to new events.

I might be able to fix the shader, but most of the cruft is on the engine's end.

[Argh]

Found the relevant section of the map drawer that handles LOD. Starts with this line:

Code: Select all

//!rita yttre begr?snings yta mot n?ta lod

Found that it's all tied into these two lines, ultimately:

Code: Select all

  float cx2 = camera->pos.x / SQUARE_SIZE;
  float cy2 = camera->pos.z / SQUARE_SIZE;

Which should instead be an interception from the camera XYZ to the ground, such as this:

Code: Select all

void CBFGroundDrawer::AddFrustumRestraint(const float3& side)
{
  fline temp;
  static const float3 up(0, 1, 0);
 
  // get vector for collision between frustum and horizontal plane
  float3 b = up.cross(side);
 
  if (fabs(b.z) < 0.0001f)
    b.z = 0.0001f;
 
  {
    temp.dir = b.x / b.z; // set direction to that
    float3 c = b.cross(side); // get vector from camera to collision line
    float3 colpoint; // a point on the collision line
 
    if (side.y > 0)
      colpoint = cam2->pos - c * ((cam2->pos.y - (readmap->currMinHeight - 100)) / c.y);
    else
      colpoint = cam2->pos - c * ((cam2->pos.y - (readmap->currMaxHeight + 30)) / c.y);
 
    // get intersection between colpoint and z axis
    temp.base = (colpoint.x - colpoint.z * temp.dir) / SQUARE_SIZE;
 
    if (b.z > 0) {
      left.push_back(temp);
    } else {
      right.push_back(temp);
    }
  }
}