Two college programmers seeking to contribute

[sangbo]

Hello!

We are Sang Tian and Boya Yang and we are two college undergraduates (junior and senior) from Carnegie Mellon University. We are very interested in contributing to this open source game for a term project for a class called "Foundations of Software Engineering". We have some experience with programming in C++ and OpenGL and we plan to spend approximately 50 hours working on this project. We are wondering whether there are any specific features of this game that we can help to implement or improve. All suggestions welcome! Again, we are very excited to begin working on this awesome game!

Thanks!

Sang Tian and Boya Yang

[zoot]

Welcome to the forum. I am not part of the team, but I believe some of the most wanted features are listed here: http://trac.wildfiregames.com/wiki/GameplayFeatureStatus

[myconid]

Hey there! I might have an interesting task for you, should you wish to accept it.

As you may be aware, in Alpha 11 there's been a lot of progress revamping the game's graphics code. For example, we've added support for normal and specular mapping, among many other things. However, the new effects have only been implemented in the high-level GLSL shaders, but not the older (and more widely compatible) ARB assembly shaders. Team member wraitii did some work porting them over, but that was some time ago, so his code is fairly out of date by now. I've been meaning to remedy that for a while, but other tasks and real-life obligations have been getting in the way.

Your job would be to port the GLSL shaders to ARB. You can choose to update wraitii's code, or not - I leave it to your judgement. This will involve a bit of coding in C++ and quite a bit of coding in GPU assembly.

[sangbo]

Hello!

Thanks for the great suggestion! We would love to do it!

We have some background in computer graphics, but limited knowledge about GLSL and ARB assembly shaders. If possible, could you provide some information that can help us get started?

Thanks!

[myconid]

Great!

I think the easiest way to get acquainted with how shaders work is to examine the existing shaders in binaries/data/mods/public/shaders/ and also wraitii code on github (hopefully that's the latest version, I'll poke him to check).

GLSL syntax is fairly straightforward and all the functions are very well documented on OpenGL's website/wiki (look at Wikipedia's article for a general introduction). Documentation for ARB assembly is a little harder to come by these days, so for starters I highly recommend looking at Wikipedia and the ARB parts of this extremely handy reference sheet, and also any specs you can find on OpenGL's website.

There are two elements to your task: first you need to pass the relevant parameters from the C++ into the ARB shaders (I believe wraitii already implemented a solution for this, using the texture coordinate registers, but IIRC it needs some cleaning up). Then, most of the work is in rewriting the shaders themselves in assembly. The main shaders used for model and terrain rendering are model_common.* and terrain_common.*, in both the GLSL and ARB directories, and there are other shaders for water effects etc. You should start with the model and terrain shaders, but then continue until the GLSL/ARB shader sets are as identical as possible (depending on how much time you have available).

I should mention that Nvidia's free CG toolkit has the ability to convert GLSL to ARB automatically, but I don't know how practical it is to use in our case. Worth checking out.

Of course, I'll be here if you have any questions or need any help.

[wraitii]

My code is not up to date, but generally it should not have changed a lot so it should be pretty straightforward.

ARB is extremely basic, and indeed the reference is a godsend. It's quite annoying, but it's really really predictable.

If you want to give my code a go and have problems, I could likely help.

(BTW, the latest version of my patch is on TRAC, on the ticket 1572.)

[sangbo]

We are working on the translation, and we have a few questions:

1. Do ARB shaders read parameters passed in from the c++ program in the same way that GLSL shaders do? Where in the c++ code are the parameters defined and passed into the shaders?

2. Is there a way to test if our translation compiles/works/runs?

3. How do we submit our code to the development team for inspection after we are done?

[myconid]

1. Do ARB shaders read parameters passed in from the c++ program in the same way that GLSL shaders do? Where in the c++ code are the parameters defined and passed into the shaders?

Yes, both types of shaders use the same interfaces. In graphics/ShaderProgram.cpp, there's a parent CShaderProgram class and also derived classes for CShaderProgramGLSL and CShaderProgramARB (there's also some related stuff for the "FFP" fixed function pipeline, though you won't need to worry about those). The code to load/parse the shader xml files is in graphics/ShaderManager.cpp. The parameters are passed to the shaders from the renderers. I think the only renderer file you might need to modify is renderer/InstancingModelRenderer.cpp.

Now, the challenge you'll need to overcome on the C++ side is that ARB can't receive parameters as VertexAttribPointer. Instead, you'll need to pass them as texcoords or some other basic type. wraitii had a solution for this in his code which you may be able to use/improve, so I recommend checking what changes he made to ShaderProgram and InstancingModelRenderer.

2. Is there a way to test if our translation compiles/works/runs?

In your config file, set preferglsl=false, gentangents=true, materialmgr.quality=10. This will select the ARB shaders, generate tangents for instanced objects (necessary for normal and parallax mapping) and try to compile shaders for advanced effects.

3. How do we submit our code to the development team for inspection after we are done?

You can open a ticket on Trac and submit a patch there. If you want, you can also fork our Github repo and push changes on there as you work (this will make it easier for you to collaborate, and that's some Good Software Engineering right there ).

[sangbo]

Hi.

The code below is part of the translation for the model_common vertex shader (only the section on wind is not yet translated). We are relatively new to ARB shader language and so we are hoping to get some feedback on whether we are on the right track. While translating, we noticed some uniform variables (e.g. shadowScale, windData) that were used in the shader which needs to be called in the vertex shader, but we were not able to find the location where these variables were set (to get the index into program.local). So, where are the following variables set: cameraPos, sunDir, sunColor, losTransform, shadowTransform, instancingTransform, shadowScale, sim_time, windData ?

!!ARBvp1.0
PARAM cameraPos = program.local[0];
PARAM sunDir = program.local[1];
PARAM sunColor = program.local[2];
PARAM losTransform = program.local[3];
PARAM shadowTransform[4] = { program.local[4..7] };
PARAM instancingTransform[4] = { program.local[8..11] };

#if USE_SHADOW_SAMPLER && USE_SHADOW_PCF
  PARAM shadowScale = program.local[12];
#endif
#if USE_WIND
  PARAM sim_time = program.local[13];
  PARAM windData = program.local[14];
#endif
OUTPUT v_lighting;
OUTPUT v_tex = result.texcoord[0];
OUTPUT v_los = result.texcoord[1];
#if USE_SHADOW
  OUTPUT v_shadow = result.texcoord[2];
#endif
#if USE_INSTANCING && USE_AO
  OUTPUT v_tex2 = result.texcoord[3];
#endif
#if USE_SPECULAR || USE_NORMAL_MAP || USE_SPECULAR_MAP || USE_PARALLAX_MAP
  OUTPUT v_normal = result.texcoord[4];
  #if USE_INSTANCING && (USE_NORMAL_MAP || USE_PARALLAX_MAP)
    OUTPUT v_tangent = result.texcoord[4];
  #endif
  #if USE_SPECULAR || USE_SPECULAR_MAP
OUTPUT v_half = result.texcoord[5];
  #endif
  #if USE_INSTANCING && USE_PARALLAX_MAP
OUTPUT v_eyeVec = result.texcoord[6];
  #endif
#endif
//// Compute position and normal:
#if USE_INSTANCING
  TEMP position;
  TEMP normal;
  DP4 position.x, instancingTransform[0], vertex.position;
  DP4 position.y, instancingTransform[1], vertex.position;
  DP4 position.z, instancingTransform[2], vertex.position;
  MOV position.w, 1.0;
  DP3 normal.x, instancingTransform[0], vertex.normal;
  DP3 normal.y, instancingTransform[1], vertex.normal;
  DP3 normal.z, instancingTransform[2], vertex.normal;
  #if (USE_NORMAL_MAP || USE_PARALLAX_MAP)
    DP3 tangent.x, instancingTransform[0], vertex.tangent;
DP3 tangent.y, instancingTransform[1], vertex.tangent;
DP3 tangent.z, instancingTransform[2], vertex.tangent;
  #endif
#else
  ATTRIB position = vertex.position;
  ATTRIB normal = vertex.normal;
#endif
#if USE_WIND
  TEMP wind;
  MOV wind, windData.xy;
  // ...

#endif
DP4 result.position.x, state.matrix.mvp.row[0], position;
DP4 result.position.y, state.matrix.mvp.row[1], position;
DP4 result.position.z, state.matrix.mvp.row[2], position;
DP4 result.position.w, state.matrix.mvp.row[3], position;
//// Compute lighting:
#if USE_SPECULAR || USE_NORMAL_MAP || USE_SPECULAR_MAP || USE_PARALLAX_MAP
  MOV v_normal, normal;
  #if USE_INSTANCING && (USE_NORMAL_MAP || USE_PARALLAX_MAP)
    MOV v_tangent, tangent;
TEMP normalXtangent;
XPD normalXtangent, v_normal.xyz, v_tangent.xyz;
TEMP bitangent;
MOV bitangent, normalXtangent, a_tangent.w;
MOV v_normal.w, bitangent.x;
MOV v_tangent.w, bitangent.y;
MOV v_lighting.w, bitangent.z;
  #endif

  #if USE_SPECULAR || USE_SPECULAR_MAP || USE_PARALLAX_MAP
    // eyeVec = cameraPos.xyz - position.xyz;
    TEMP eyeVec;
    SUB eyeVec.xyz, cameraPos, position;
    #if USE_SPECULAR || USE_SPECULAR_MAP
   // v_half = normalize(-sunDir + eyeVec);
	  TEMP half;
	  SUB half.xyz, eyeVec, sunDir;
	  DP3 half.w, half, half;
	  RSQ half.w, half.w;
	  MUL v_half.xyz, half, half.w;
#endif
#if USE_INSTANCING && USE_PARALLAX_MAP
   MOV v_eyeVec, eyeVec;
    #endif
  #endif
#endif

// v_lighting.xyz = max(0.0, dot(normal, -sunDir)) * sunColor;
DP3 lighting, normal, -sunDir;
MAX lighting, 0.0, lighting;
MUL result.color, lighting, sunColor;
//// Texture coordinates:
MOV v_tex, vertex.texcoord[0];
#if USE_INSTANCING && USE_AO
  MOV v_tex2, vertex.texcoord[1];
#endif

#if USE_SHADOW
  // v_shadow = shadowTransform * position;
  DP4 v_shadow.x, shadowTransform[0], position;
  DP4 v_shadow.y, shadowTransform[1], position;
  DP4 v_shadow.z, shadowTransform[2], position;
  DP4 v_shadow.w, shadowTransform[3], position;
  #if USE_SHADOW_SAMPLER && USE_SHADOW_PCF
    // v_shadow.xy *= shadowScale.xy;
   DP2 v_shadow.xy, v_shadow.xy, shadowScale;
  #endif
#endif
MAD v_los, position.xz, losTransform.x, losTransform.y;
END

[myconid]

While translating, we noticed some uniform variables (e.g. shadowScale, windData) that were used in the shader which needs to be called in the vertex shader, but we were not able to find the location where these variables were set (to get the index into program.local). So, where are the following variables set: cameraPos, sunDir, sunColor, losTransform, shadowTransform, instancingTransform, shadowScale, sim_time, windData ?

Nice work, great to see some progress!

The values of some of those variables are set in renderer/RenderModifiers.cpp, while others are set dynamically though the materials system and bound in renderer/ModelRenderer.cpp. However, you don't need to worry about what sets those values, as the mapping from identifiers to indices is stored explicitly in each shader's xml, i.e. you should only need to change shaders/arb/model_common.xml.

Btw, I don't know if there've been any changes to our shadow code recently, so make sure you aren't undoing any optimisations by modifying the "USE_SHADOW" stuff.

[wraitii]

Having translated those before (pre wind-changes and many other stuffs), your code seems allright. You're using the same texCoord (4) for both v_tangent and v_normal in some cases though.

Also, if you hit the hard limit of 8 texCoords, you may want to put some things together to use the 4 coordinates (can't recall exactly, but perhaps v_los is only 2 parameters for example, and could be put with v_tex). Dunno if you'll need it, I seem to recall having to do it but that may have been before some optimizations in the code/myconid's work.

[sangbo]

Hi again,

We're working on modifying ShaderProgram.cpp to get ARB to recognize vertex attribute pointers, and we are having trouble conceptualizing what needs to be done here. The idea that we think is the appropriate way to handle things is to dissect the attribute array so that we can include the data as texture coordinates. But the problem is, what if we run out of texture coordinates? Resorting to local variables does not seem like a very practical solution.

Also, we're not sure how to view wraitii's patch, so we can't exactly see how he attempted to solve this problem.

Is gpu skinning possibly enabled in the ARB shader? We were under the impression that it cannot be used and has ignored shader code relevant to gpu skinning for now. Is our assumption correct?

[myconid]

You don't need to dissect the attributes yourselves, as you can tell OpenGL to do it for you. The idea is to use the parameters of CShaderProgram::VertexAttribPointer in a CShaderProgram::TexCoordPointer call. You can do this straight from the InstancingModelRenderer::PrepareModelDef, with a fixed texture index (e.g. 2).

You can view a patch with the text editor (where it'll look like instructions to add/remove lines in specific methods/files). You could also try to apply it (google for a tutorial), though since it's out of date you'll probably run into conflicts.

Ignore the GPU skinning stuff, for now.