[http://sourceforge.net/p/ufoai/patches/519 Item 519] imported from sourceforge.net tracker on 2013-01-28 20:43:43

This patch should hopefully cleanup the light fragment shader code a little bit - i would like to hear your oppinion.

I also had to limit the amount of lights to 4 to let my crappy ati glsl compiler accept this shader. glGetInteger GL_MAX_LIGHTS returns 8 on this card (this is a must afaik) but accessing gl_LightSource[idx] where idx >= 4 result in a message like "Shader not supported by HW" - if you see a reason or a settings that we can query at init and set in the shader, that would be quite cool.
===== Comments Ported from Sourceforge =====

====== tlh2000 (2010-04-21 16:29:58) ======

oh, before i forget this - once i get the shader to compile the whole map (brushes) are only black - any idea why?
====== arisian (2010-04-21 17:44:48) ======

Heh, I was just looking at that code this morning and thinking it was a mess...I'm at work now, but I'll test it later. Oh, the one thing that I did spot looking at it is the fact that you have your "light" vec3 as an "out" parameter for that function; it should be "inout" given that the operation is +=. I suspect that may be why your brushes are black; it's effectively only factoring in the last light, so if that last light isn't used, you get black.
====== tlh2000 (2010-04-21 18:25:46) ======

thanks - tried that, no change, still everything black
====== arisian (2010-04-21 23:58:27) ======

I've attached another patch, which does much the same thing, only I had already done it when you posted your first patch. It works on my system; let me know what it does on yours...
====== arisian (2010-04-22 00:26:59) ======

The current SVN version doesn't compile cleanly for me, and the patches are getting confusing. I've just attached the actual light_fs.glsl file I'm using now; it works here, but you should test it there. I *think* it incorporates the important parts of both your patch and mine.
====== arisian (2010-04-22 01:51:25) ======

Also, FYI, I'm thinking about merging the "mesh" and "world" shader programs; with only very minor additions, the "world" shader program can be used for mesh rendering as well. This should make it much easier to use things like normalmaps, etc. with models/meshes.
====== tlh2000 (2010-04-22 06:16:24) ======

you removed the r_lights cvar check and so on - as well as the ATTENUATION define

also using the call like
void LightContribution(gl_LightSourceParameters param, inout vec3 light){
would be better imo as the gl_LightSource[i] stuff is the reason it does not compile on other cards, thus i tried to reduce tha amount of direct accesses to this to be able to fix it with one call.

what is the error you get when you compile the shader?
====== tlh2000 (2010-04-22 06:21:09) ======

one other note:
the normalize and dot calls are only needed when dist is inside the attenuation radius of the light

vec3 dir = normalize(delta);
float d = dot(normal, dir);

so imo we should only calculate it then
====== tlh2000 (2010-04-22 06:23:09) ======

i've attached another version which merges some of your changes into the shader, too - please try that one on your card.
====== tlh2000 (2010-04-22 06:26:43) ======

sidenote: ftransform is deprecated:

Note that ftransform() is no longer available since GLSL 1.40 and GLSL ES 1.0. Instead, the programmer has to manage the projection and modelview matrices explicitly in order to comply with the new OpenGL 3.1 standard

http://www.opengl.org/registry/doc/GLSLangSpec.4.00.7.pdf

when we are already on it we should maybe also replace deprecated stuff to improve compatibility
====== arisian (2010-04-22 12:28:18) ======

The issue I had yesterday was that there was an un-matched #if r_light, which I think is why I took that out (I wasn't sure where the #endif was supposed to go). As for passing the light rather than an integer, that's fine by me. If it's compatible with more systems, go for it. The reason I'd taken out the #define ATTENUATION was that I thought it might be causing some of the compatibility problems, and once you make a function to do the attenuation, you only need to write the formula once anyway (the reason it was a #define before, I assume, was because it got used 8 times).

And yes, I agree, we should try to make things conform better to the standard. I'll try to find time to actually read through that PDF and see what's deprecated and what's not.
====== arisian (2010-04-22 12:47:02) ======

Also, if we're going to standardize things using version 4.0 of the standard, we need to include #version statements in the shaders; most of them don't have any right now, which the spec says will be interpreted as using version 1.1.
====== tlh2000 (2010-04-22 13:04:54) ======

we should go as low as possible with the version
====== arisian (2010-04-22 14:11:18) ======

Can you run some experiments on your machine to see what version numbers work for you? In particular, try both with and without the "compatibility" profile; I'd like to use as recent a version of the spec as is usable by everyone.
====== tlh2000 (2010-04-22 14:38:30) ======

i will perform some tests in the evening
====== arisian (2010-04-23 00:29:37) ======

I've just attached a new patch that moves the functionality of the "mesh" program into the "world" program; it seems silly to have both, since they do essentially the same thing except for the fact that the "mesh" program doesn't do bumpmapping. Since we would like to add that feature to meshes eventually, it seemed better to have one shader program rather than two. Everything works perfectly on my system using this patch; everything that should glow does, everything that should be lit is, etc.

If it works for you, feel free to commit it. Otherwise, let me know what you think.
====== tlh2000 (2010-04-23 05:27:00) ======

looks good, except the fact that in and out are not supported for global variables on my card. haven't digged the documentation whether this should be valid or not, but for the compatibility reasons we should avoid using in and out for varyings and uniforms. i still have to apply the patch on my second machine to check it. will keep you informed. i will spend most of my day in a train - so maybe you will first hear from me tomorrow (if not i found wlan in the train ;) )
====== tlh2000 (2010-04-23 05:53:45) ======

getting these errors when trying to compile the shader.

R_LoadShader: world_vs.glsl: Vertex shader failed to compile with the following errors:
ERROR: 0:120: Compiler error: unexpected qualifier
ERROR: error(#273) 0 compilation errors. No code generated


R_LoadShader: world_fs.glsl: Fragment shader failed to compile with the following errors:
ERROR: 0:171: error(#160) Cannot convert from '3-component vector of float' to 'float'
WARNING: 0:178: warning(#283) Implicit cast from int to float
WARNING: 0:178: warning(#283) Implicit cast from int to float
WARNING: 0:178: warning(#283) Implicit cast from int to float
ERROR: 0:179: error(#160) Cannot convert from '3-component vector of float' to 'float'
WARNING: 0:195: warning(#283) Implicit cast from int to float
ERROR: error(#273) 2 compilation errors. No code generated


R_LoadProgram: world: Warning: No shaders attached to current program

R_LoadProgram: 'mesh' loaded.
R_LoadProgram: 'warp' loaded.
R_LoadProgram: 'geoscape' loaded.
R_LoadProgram: 'combine2' loaded.
R_LoadProgram: 'convolve3' loaded.
R_LoadProgram: 'atmosphere' loaded.
R_LoadProgram: 'simple_glow' loaded.

====== tlh2000 (2010-04-23 06:07:32) ======

i have assigned some of your changes to trunk already, this makes the patch a little bit smaller, attached is a new version that also fixes two of the glsl errors (in and out for variying lighpos removed)
====== arisian (2010-04-23 13:04:17) ======

Okay, I've just attached a new patch; I think it should fix the issues you mentioned in the GLSL. I really wish that the NVidia GLSL compiler would be a bit noisier about things...I'm thinking I may actually need to try to set up a build environment for ufoai under Windows just so I can use the windows-only GLSL tools like nvemulate, but I really hate developing under windows...
====== arisian (2010-04-23 13:40:08) ======

I've added #version statements to the beginning of the glsl files; doing so seems to help my compiler give useful error messages. Using #version 110 gets me most of the same errors that you mention below, where otherwise the compiler seems to just take care of these things behind my back. I'm still not sure what version we actually want to be using, but 110 is as low as we can go and still have the existing shaders compile, as far as I can tell.
====== tlh2000 (2010-04-23 20:53:47) ======

applied to trunk now - feel free to merge them now.
====== arisian (2010-04-23 22:42:06) ======

Actually, they're already merged; the mesh program isn't used at all in the current SVN trunk. The only question is whether we want to actually remove the file (and the pointer in r_state) or not.
====== arisian (2010-04-23 22:44:40) ======

Also, what happened to your patch for light_fs.glsl? I thought it got put into the trunk, but now it seems to be the old version again.
====== tlh2000 (2010-04-24 06:58:46) ======

yes. i've reverted it, because some cards seems to have problems with for loops - that's why i unrolled them again. we have to take a second look at that code.
====== tlh2000 (2010-04-24 07:00:33) ======

what about the offset parameter for the mesh program? it's needed for the warping shell effect.
====== arisian (2010-04-24 17:39:38) ======

The "offset" parameter is now included in the world_vs.glsl shader. The separate "warp" shader (warp_vs/fs.glsl) I haven't done anything with; it's unmodified and should still be in use. I haven't really looked at it very hard, so I'm not actually sure what the "warp" shader is getting used for (it's not used for the "shell" effect so far as I can tell). I could try to merge that code into the "world" shader as well.
====== arisian (2010-04-24 21:30:42) ======

the r_postprocess cvar is now used to decide whether to use gl_FragData or gl_FragColor
====== arisian (2010-04-24 21:32:54) ======

I've just attached another small patch; this one adds #if/else blocks to the shaders so that the code with gl_FragData[] only gets included if r_postprocess is active; otherwise, gl_FragColor code gets included instead. I'm hoping this might fix the issue geever was talking about with cards/drivers that don't support framebuffer objects. I also added a bit of code to the shader loading function in r_program.c so that it can handle #else.
====== arisian (2010-04-24 23:42:45) ======

light_fs shader using the new #unroll macro
====== arisian (2010-04-24 23:45:57) ======

I've also attached a version of the light_fs.glsl shader which makes use of the new shader macro I hacked together. Basically, it does automatic loop-unrolling when the shader source is read. It's not terribly flexible, but it lets you use a cvar to determine how many times the pseudo-loop should happen, and it gives you access to a counter variable through the special character "$"; I've used it to streamline the lighting shader code, allowing us to have some of the advantages of a loop without all the drawbacks. It will also allow a user to choose how many light sources to make use of, which might be useful if we ever actually *have* any dynamic light sources; as far as I know, none exist at the moment.
====== arisian (2010-04-25 02:25:46) ======

Okay, so, here's the thing. The current codebase does not calculate lighting for models. There's a bunch of code that *looks* like it should calculate lighting, but as far as I can tell, we could replace all of mesh_fs.glsl (including the "include" files and function calls) with the line "gl_FragColor = 0.5 * texture2D(SAMPLER0, gl_TexCoord[0].st + offset);" because that's what's actually getting done. There are several issues that cause this, but the most major one is that models don't have normal vectors. Every normal vector for every vertex of every model is {0, 0, 0, 0}. On top of this, the "light position" of the static light for all actors seems to be {0, 0, 0, 0} as well. This means that the line which *should* calculate the lighting (line 28 in mesh_fs.glsl) in fact reduces to max(0.5, 0.0) for every single call.

Did I somehow do something that totally broke this for me, or has it really been that broken all along? Can you verify this (the quickest thing to do is change the max() call to max(0.0, pow(2.0 * dot(normal, lightdir), 2.0)) and see if everything turns black)?
====== tlh2000 (2010-04-25 10:48:45) ======

holy shit - you are right - there are no normals generated for md2 models. that would explain so many display problems....
====== tlh2000 (2010-04-25 11:18:03) ======

i've added code for thsi in r29548 - R_CalcAliasNormals - but currently deactivated. must be optimized a little bit, it increases load times a lot.
====== arisian (2010-04-25 12:19:30) ======

While we're at it, we should generate tangents as well as normals, since they're required for bumpmapping and other "advanced" rendering techniques. If it's too expensive to calculate on the fly, maybe we should pre-calculate them and store them as an extra file on disk? eg. you might have "mymodel.md2" and you'd also have "mymodel.md2xtra" (or whatever extension you want) which would contain the normals and tangents, and would be read/written along with the actual model.
====== tlh2000 (2010-04-25 12:25:17) ======

if you could contribute the code for calculating tangents for obj, md2 and md3 as well as the dpm model loading code (should be a general function that is working for all of them after they were loaded to the mAlias*_t structures) i would like to write a tool that would do that for all of our models.
====== arisian (2010-04-25 12:26:55) ======

Okay, I'll take a crack at it and post it here when I'm done.
====== arisian (2010-04-25 13:27:52) ======

I've added code that I *think* should calculate the tangents into your R_CalcAliasNormals function in r29561. The function is still deactivated, and I currently have no way to test/debug the code, but it's there.
====== arisian (2010-04-25 13:35:39) ======

Also, the map-specific material-based objects currently do have both normals and tangents that are defined (I assume they're correct, though I haven't actually looked that hard). I've got no idea when or where those tangents get generated, but the bumpmapping shader code has always made use of them via the TANGENT attribute.
====== tlh2000 (2010-04-25 13:46:34) ======

thanks - but this would only work for md2 models, implementing this on the mAlias*_t structures should be the goal imo. normals are loaded from dpm, md3 and obj already, only md2 was missing, that's why i've added this into the md2-only code. but the tangents are needed for every other model format, too
====== tlh2000 (2010-04-25 14:14:09) ======

added tangent function preparation into r29564
====== arisian (2010-04-25 14:25:06) ======

That code should work on anything that has mAliasVertex_t and mAliasCoord_t pointers; the only reason I added it to your function was that it required a bunch of the same steps, so it seemed silly to do them all again. What other types besides mAliasMesh_t does the tangent generator need to operate on? If it's just a matter of generating the static version and putting it into the float* pointer, that should be easy enough as long as you can point me to some code that demonstrates how it's supposed to be structured (eg. code for the normals or vertexes).
====== arisian (2010-04-25 14:39:40) ======

Also, I found where the tangents for the .bsp meshes get created; it's in r_model_brush.c, and it turns out there's actually some code in common/mathlib.c that does some of the tangent generation already. It doesn't do smoothing (ie. averaging the normals for triangles that share a vertex), but if the normals have already been smoothed, then it might not matter. I'm still a bit unsettled by the fact that it only uses the texture coordinates and makes no reference to object-space vertex coordinates, but maybe I'm just missing something.
====== tlh2000 (2010-04-25 14:43:03) ======

would be nice if you could have a look at my changes:
https://sourceforge.net/apps/trac/ufoai/changeset/29564
https://sourceforge.net/apps/trac/ufoai/changeset/29565

i'm on a machine without shaders right now. if you see something bad, please let me know.
====== tlh2000 (2010-04-25 14:44:34) ======

about the tangent calculation - not every model format loader must calculate the normals on its own - e.g. md3, obj and dpm already includes them - that's why it should be possible to calculate tangents only. but as they should be loaded from a file later anyway it maybe doesn't matter that much. i will check that stuff.
====== arisian (2010-04-25 15:01:54) ======

Latest SVN seems to have some slightly odd behavior; it looks as though there are normal maps that are getting applied to BSP models from some camera perspectives, but not from others. Normal vectors for MD2 models are still 0, because the normal calculation function is commented out. If I uncomment it, very strange things happen, including missing models (eg. heads, dropship), and odd rendering of the ones that do exist (eg. mostly black, but some are green or gray instead).
====== tlh2000 (2010-04-25 15:07:06) ======


====== tlh2000 (2010-04-25 15:08:54) ======

attached a small patch - could you please try whether that fixes anything? that should be the only changed behaviour from r29565 - r29564 should not change anything of the handling as the tangents are not even used for meshes, yet.
====== arisian (2010-04-25 15:11:49) ======

screenshot of odd "normal map" behavior
====== arisian (2010-04-25 15:12:13) ======

same scene, different camera position
====== arisian (2010-04-25 15:12:35) ======

It looks the same here; check out the screenshots I just attached to see what I'm talking about.
====== arisian (2010-04-25 15:17:46) ======

Your patch did change what surfaces this affect appears on, though.
====== tlh2000 (2010-04-25 15:23:49) ======

there was a bug in the per-triangle tangents and cotangents calculation - the vectorcopy calls did mix the src and dest pointers.
====== tlh2000 (2010-04-25 15:25:23) ======

can you please try to check which revision introduced this by going back some revs?
====== arisian (2010-04-25 15:41:43) ======

r29565 seems to have introduced the "ridges" effect; it was not present in r29564.
====== tlh2000 (2010-04-25 15:53:37) ======

thanks - maybe i'm blind, but i really don't see what could have broken it in that revision

https://sourceforge.net/apps/trac/ufoai/changeset/29565
====== tlh2000 (2010-04-25 15:54:37) ======

it doesn't look like the error is for material affected surfaces, but for surfaces without a material definition, no?
====== arisian (2010-04-25 16:34:23) ======

My guess would be that R_UseMaterial() isn't getting called in all the same places it was before
====== tlh2000 (2010-04-25 16:52:48) ======

yes - i've fixed one issue with it in r29572
====== arisian (2010-04-25 17:30:24) ======

Well, despite the "ridges," this does seem to have fixed some of the other issues; the bugs with the black patches (eg. on the brick walls in +mart) seem to be gone.
====== tlh2000 (2010-04-25 18:02:29) ======

i really don't see any other difference that wasn't fixed in the meantime.
====== arisian (2010-04-25 18:04:21) ======

Look at line 77 of r_surface.c; how sure are you that surf->texinfo->image->material points to the same thing that stage->image->material? The former is what's used in the R_UseMaterial call now, the latter is what got used before.
====== tlh2000 (2010-04-25 18:05:19) ======

found it - see src/client/renderer/r_state.c of r29577
====== tlh2000 (2010-04-25 18:06:52) ======

now feel free to add bump mapping for mesh models - assume you generate the tangents and normals at load time. i will write the tool to precalc the data for all our models and integrate it once i'm done.
====== arisian (2010-04-25 18:07:07) ======

That seems to fix it; everything looks good for me in r29577
====== arisian (2010-04-25 18:25:28) ======

Okay, r29580 has bump-mapping code which should work with meshes, I think. The meshes still have 0 vectors for their normals, and the parameters like HARDNESS and SPECULARITY should be set somehow, since right now they're just leftover from whatever the last material to get loaded was. The actual code in the shader that does calls the bumpmapping function is currently commented out so people don't get black models.

Also, there's a bunch of new code in the shaders to handle dynamic lights better, but we don't actually have any dynamic lights, so it isn't used at the moment.
====== tlh2000 (2010-04-25 19:54:20) ======

what do you mean with dynamic lights? we have up to 8 light sources already.
====== arisian (2010-04-25 19:58:14) ======

The code in light_fs.glsl only calculates the attenuated color/intensity from each light; I want to be able to do things like bump-mapping on a per-light basis as well. Also, I figured that given how your system responds to 8 light sources, and also the potential performance impact of having that many dynamic lights, it would be better to use a cvar for how many dynamic lights to use, so there's an option in the graphics menu for that now.
====== tlh2000 (2010-04-25 20:11:38) ======

as we've never used 8 lights at the same time yet, nobody reported any performance issues - but if you think that could speed things up - please introduce a cvar for it.

btw. which models are you using for testing the bump mapping? do we already have normalmaps for some of them? otherwise we have some normalmaps by MCR in the forum, not sure whether they will work or whetehr you need them to be encoded in a special way (like for brushes with height in its alpha)
====== arisian (2010-04-25 20:20:41) ======

I've got a copy of a normal-map for the dropship that MCR made, but I still haven't managed to get to the point where I have non-zero normal vectors for the meshes yet. I'd like to get un-bumpmapped static lighting working first. The normals are getting generated, but somehow by the time they get loaded into the GL array, they're all zeros again.
====== arisian (2010-04-25 20:26:20) ======

I think it has something to do with the animation frames.
====== arisian (2010-04-25 20:48:22) ======

Okay, solved it partially; the soldier bodies now have well-defined normals, though weapons, heads, etc. still don't. I've committed the changes in r29585.
====== arisian (2010-04-25 20:53:17) ======

Oh, and the reason no one has reported performance issues is that we haven't used *any* lights yet ;)
====== tlh2000 (2010-04-25 20:56:56) ======

hm? we had used lights, no? see R_AddLight - or are we talking about different things here?

so now normals and tangents are working for animated models, but not for stills?

oh and please deactivate the debug output from your previous commit again if no longer needed.
====== arisian (2010-04-25 21:03:01) ======

Actually, that debug output is meaningful; the fact that those normals are of length zero indicates a problem. I don't know what that problem is yet; if you can figure it out and fix it, feel free to remove the debug output.

Do the static models actually use the vertexes[] array, or do they just use the float pointers? If the latter, then the reason they don't work is that the data we're reading from when generating the normals is the vertex arrays, not the float pointers.

But yes, normals now work for the animated models (or at least, are of non-zero length). I haven't actually checked the tangents yet.
====== arisian (2010-04-25 21:11:57) ======

And as for dynamic lights, as far as I can tell the only code that actually calls R_AddLight is the particle code, which uses it for brief effects like explosions. Are there any dynamic lights that last more than a few frames?
====== arisian (2010-04-25 21:50:06) ======

Okay, as of r29586 all models seem to be getting normals that are the correct length (ie. non-zero). I'm still not sure if they have the correct values, but at least it's a start.
====== arisian (2010-04-26 02:25:56) ======

I still don't think the normals are actually correct; as a quick test, I tried changing world_fs.glsl so that it would render a shade equal to the dot product of the normal vector and the view vector; I've attached an image that shows the result. On reflection, maybe doing that whole "smoothing" thing isn't such a great idea after all; at the very least, we should probably make it optional. I'm not sure if that's the only problem or if there's something else going on here; I'll take another look at it tomorrow.
====== arisian (2010-04-26 02:26:35) ======

intensity = dot( normal, normalize(eyevec) );
====== tlh2000 (2010-04-26 06:17:56) ======

i'm almost done with creating the 'mdx' files with a new tool called ufomodel. only FS_BuildFileList must now be patched to work with something like **.md2. will try to finish it in the evening.
====== arisian (2010-04-26 13:30:10) ======

Okay, I think I've convinced myself that the normals are getting correctly generated now. I think I'm going to go back and take another look at the averaging code, though; I think it might be better to only average them together if they're close enough to start with. As it is now, we do the averaging even for acute angles, which makes for some slight visual oddities.
====== tlh2000 (2010-04-26 15:13:51) ======

are any of the effects already visible? if yes, which map? which model?
====== arisian (2010-04-26 15:34:22) ======

No, not in the "normal" renderer. I'm still working with a hacked version of the world shader that colors objects based on debugging parameters. I don't want to commit this stuff to trunk until I've got it cleaned up some more. Also, I think the normals are right, but I think the tangents might still be off, so the bumpmapping doesn't work right yet.
====== arisian (2010-04-26 15:34:40) ======

By "normal renderer" I mean the "standard" renderer.
====== tlh2000 (2010-04-26 19:24:47) ======

most of the code of the new tool is in the svn now - there is still a c::b project missing. will try to do that tomorrow.
====== tlh2000 (2010-04-26 19:36:20) ======

R_LoadProgram: world: Fragment shader(s) failed to link, vertex shader(s) failed to link.
Shader wrote to 'gl_FragColor' and 'gl_FragData', only one can be written to.
Shader wrote to 'gl_FragColor' and 'gl_FragData', only one can be written to.

R_LoadProgram: warp: Fragment shader(s) failed to link, vertex shader(s) failed to link.
Shader wrote to 'gl_FragColor' and 'gl_FragData', only one can be written to.
Shader wrote to 'gl_FragColor' and 'gl_FragData', only one can be written to.


====== arisian (2010-04-26 22:57:05) ======

That's strange, only one of them should ever actually get included, due to the #if #else blocks. Is postprocessing enabled or disabled?
====== arisian (2010-04-27 01:45:16) ======

bumpmapped dropship (no color texture)
====== arisian (2010-04-27 01:45:42) ======

bumpmapped dropship (with color texture)
====== arisian (2010-04-27 01:59:12) ======

Okay, I finally found the bug with the tangents that I've been chasing for the past two days. Turns out, the tangent generating code was fine, the problem was that the tangent array setup for the shader was treating the tangent array as 3-vectors, when they're really 4-vectors. In any case, I think that bumpmapping more or less works now for md2 models (I've only tested for static models, but I think it should work with animated ones too). Screenshots below, and changes are committed in r29607. There aren't any normal-maps in the SVN for models yet, so it shouldn't have much visual impact until we get some. Oh, and it uses the same format normalmaps as the materials, with height in the alpha channel.

Parameters like BUMP, HARDNESS, and SPECULARITY still aren't being set in any particularly meaningful way for models; I put a hack into R_EnableBumpmap() so that no specularities get rendered on non-material surfaces.
====== tlh2000 (2010-04-27 05:56:42) ======

which model(s) are you using for testing this?
====== tlh2000 (2010-04-27 06:06:48) ======

dropship with normals
====== tlh2000 (2010-04-27 06:07:18) ======

fighter with normals
====== tlh2000 (2010-04-27 06:09:15) ======

the lighting for the models (see attached dropship and fighter screenshot) looks a little bit strange now imo. this is due to the (bad?) normalmaps?
====== arisian (2010-04-27 12:26:43) ======

Actually, it has more to do with the odd placement of the lights. Since we've never seen their effects before, I don't think anyone has ever bothered to make sure they were in a sensible location. There are some issues caused by the normal-smoothing we're doing as well; I think I may re-write the normal/tangent generation code to split shared-vertexes if the normals are too far off (ie. dot product below some threshold), since the smoothing just looks strange in those cases.

There are also some issues with the normal maps that MCR posted; they were mostly proof-of-concept for testing, and not really intended for in-game use I don't think. I'm not sure, but it looks to me like they were generated procedurally based on the colors/gradients in the base textures, rather than being based on some actual underlying geometry.
====== tlh2000 (2010-04-27 12:51:29) ======

it would be nice if you could have a look at ufomodel.c (especially into the WriteToFile function) whether the file layout makes sense for you.
====== tlh2000 (2010-04-27 12:53:35) ======

oh, that means the light entities in the maps are used now?
====== arisian (2010-04-27 12:58:54) ======

No, what's happening is that each model has a light source statically associated with it. As far as I can tell, these have nothing to do with the maps. What we *should* do is load light entities from the maps and then use them for rendering, but that isn't being done yet. I'm also not sure how many light entities these maps have; we'll probably need to do something clever like having each model keep track of eg. the 4 or 8 nearest light entities so only those ones get used when rendering that model.
====== tlh2000 (2010-04-27 13:33:51) ======

afaik this is already done - or should be. only lights that reach the particular entity (radius of the light) should be used for rendering. at least i hope it works like that (don't have to code here to double check my statements)
====== arisian (2010-04-27 13:36:08) ======

I'll take a look at the lighting code later; right now I'm still working on getting the normals and tangents to do what I want (right now I'm working on the smoothing issue).
====== mcr2010 (2010-04-27 16:16:27) ======

Sorry to interrupt your conversation here (just to answer some questions):

1.Those normalmaps (from the dropship) were made only for testing purposes.
2.The heightmaps for those were based on the base textures.
3.There is a additional patch with normalmaps for the Ortnok & Bloodspider waiting to be put into trunk. Those normalmaps look VERY good in-game yet already, although just light & medium armor (just the bodies) are being normalmapped @ the moment...
4.I am currently finishing the new Taman textures & would be happy to provide a patch with included normalmaps for (easy) testing purposes (just start skirmish with alien soldiers) & of course a patch for the ufo files also if you like...

====== mcr2010 (2010-04-27 16:23:59) ======

Correction:
Bodies & HEADS of the models are being normalmapped, but only if the body.md2 defines just one skin.
====== mcr2010 (2010-04-27 17:05:23) ======

Last interruption here, because I cannot delete the last comment:

Only glowmaps work for the heads of our models, normalmaps do never work !
====== tlh2000 (2010-04-27 18:01:50) ======

the starchaser interceptor models/aircraft/inter_starchaser should have a working normalmap now.
====== tlh2000 (2010-04-27 18:19:16) ======

open the game console and type "seq_start view" to see the starchaser - glowmap is still missing, but normalmap should work there
====== tlh2000 (2010-04-27 18:28:18) ======

the ufomodel c::b project file is in the svn now, too. feedback about the tool is welcome. (also about the fileformat of the mdx file)
====== tlh2000 (2010-04-27 19:09:02) ======

and now the tool is fixed and should work - will extend it with some more options in the next few days (e.g. overwrite existing mdx files)
====== arisian (2010-04-27 20:07:52) ======

Sounds good; I haven't had a chance to look at the tool yet, I've been working on trying to get normal-smoothing to actually look good. I think I've finally got it working right; there's a #define at the top of r_model_alias.c that lets you set how close two normals have to be before they get averaged (the dot product of the two normals is compared to the threshold to decide). Also, I've temporarily disabled the parallax mapping for bump-mapped meshes, because it just doesn't look right with the normal maps I've got right now.
====== tlh2000 (2010-04-27 20:32:08) ======

is it possible that there is an endless loop somewhere in your code? i can't start +africa after a quick test.
====== arisian (2010-04-27 21:11:48) ======

+africa loads fine for me
====== arisian (2010-04-27 23:16:21) ======

Just did an update, and now it's hanging; I'm looking at the changelogs now to see what happened.
====== arisian (2010-04-27 23:25:45) ======

It looks like it's looking for a non-existant file called "ufos/_hud.ufo". I've got no idea what that file is or why we're looking for it, but as far as I can tell it has nothing to do with the rendering code.
====== mcr2010 (2010-04-27 23:29:33) ======

I also have problems with starting the latest versions...
This file should be in ufos/ui if that helps... Maybe we should try to put it into ufos also ? Maybe someone has changed the path for the file somewhere ?
====== arisian (2010-04-27 23:32:05) ======

It could also be related to the changes that Mattn made earlier; there were some changes in common/files.c, and that's where the infinite loop is occurring according to GDB (it's spending an awful lot of time on line 185).
====== arisian (2010-04-27 23:41:20) ======

Try removing "0ufos.pk3"; that seems to fix the issue for me. I think there's a bug in the new file-seeking code, but I'll let Mattn fix it since he's beet working on that. In the mean time, deleting the offending pk3 file seems to offer a workaround.
====== mcr2010 (2010-04-27 23:43:21) ======

GREAT !
WORX !
====== mcr2010 (2010-04-27 23:57:41) ======

Better described - Starts again, but battlescape does not work (hangs on loading screen) & for me this is a downgrade also as on the geoscape the high textures are not loaded anymore...
====== tlh2000 (2010-04-28 16:51:31) ======

i'm done with it - added R_ModLoadMDX in http://sourceforge.net/apps/trac/ufoai/changeset/29635

now it's your turn to use that function. Please let me know whether you have any problems with it.
====== arisian (2010-05-01 02:42:40) ======

Okay, this is just getting too long and off topic. I'm going to close this thread and open a new one for the dynamic light rendering code that I'm working on now.