myconid

Version 3 .pmd files only support one set of UVs per vertex, but that doesn't mean the format can't be modified to support more UV sets in the same file.

The UVs in the models won't work for this. Either the saved models will need to be updated with new non-overlapping sets of UVs, or the game will need to unwrap the models at runtime.

AMD's proprietary driver. Driver bug was my first thought as well, though thankfully the fix is simple enough.

Hey, thanks for the info about the model renderers. This literally took 5 minutes using Blender: http://imgur.com/a/MSmGU The final image is from the vanilla game without any shaders, though obviously the diffuse textures had to be baked quite large for this to work. I think the precomputed texture method you are suggesting would definitely work and would be easy to implement, so it'd be silly of us not to implement it... Edit: Oh, before I forget, there seems to be a bug in the get_shadow() function in the model/terrain_common.fs shaders. On my system (Linux/ATI), the LOS texture gets painted where the shadowmap should be. I haven't investigated the causes of this, though a "hunch" led me to replace this: return 0.25 * ( shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets1.xy, v_shadow.z)).a + shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets1.zw, v_shadow.z)).a + shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets2.xy, v_shadow.z)).a + shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets2.zw, v_shadow.z)).a ); with this: return 0.25 * ( shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets1.xy, v_shadow.z)).b + shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets1.zw, v_shadow.z)).b + shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets2.xy, v_shadow.z)).b + shadow2D(shadowTex, vec3(v_shadow.xy + shadowOffsets2.zw, v_shadow.z)).b ); to fix it.

Nope. That's true for object-space mapping, however the thing I'll work on next should overcome that limitation. A suggestion: OK-looking maps can be generated automatically from the textures (e.g. with the GIMP), while the existing UV coords will be reused. If they choose to do so, the artists could batch-generate maps for various models, bake portions of particular types of texture (e.g. rooftiles) and simply replace parts of the batch-generated maps with the baked maps. While the sculpting/baking work for the texture-types will need to be done by the artists themselves, the rest can be done by any volunteer who can use an image editor, and the artists will just do the QA. Not the best solution, perhaps, but I hope that at least it makes sense. A question for programmers: Am I right in assuming that all skeletal objects are handled by the stuff in "renderer/HWLightingModelRenderer.*" and all statics are handled by "renderer/InstancingModelRenderer.*"? If so, I might concentrate on just the latter, which will make things much easier... A note for those holding their breaths: I'm busy with IRL stuff until the end of the week. Hopefully there'll be some more progress over the weekend.

Thanks for the heads up. Since people are wondering, here's what the filters look like in motion: http://www.2shared.com/file/GMrSa79V/out-7.html (sorry for the quality, my crappy laptop can't handle screen capturing) I don't know much about precomputed AO or its advantages/disadvantages, and I don't know if there are any games that use it (doesn't mean such games don't exist). It definitely does sound like an interesting experiment for another day, though.

What I'm working on is needed for both normal and parallax mapping. I need the tangents that define the direction of the surface of objects (which unfortunately can't be derived from UV coords or anything else normally available to the shaders). The most elegant solution would be to use Blender to export them in the Collada files and then the game takes those and uses them directly. Since Blender can't export tangents yet, I have to either find another program that can calculate them (any program, not necessarily Maya), or simply calculate them myself on the fly. At this point, the last option seems best... Which is great, because I take pleasure in messing with things like this! So, patience and I'll get there soon enough.

Hey all, Could someone with access to Maya or similar software please upload a sample Collada file that has been exported with TEXTANGENT (and/or TEXBINORMAL) info included? It looks like Blender's exporter can't handle that yet. I'm going to delve into the mesh-loading code and see how I can grab that info from FCollada. Once that's done, the rest should hopefully just fall into place. Cheers, Myc

Agreed, I started with this just because it feels simpler. The plan is to: first do proper tangent-space bump mapping for models,then the same for terrains,then parallax mapping for terrains,finally parallax for models. My thinking is that even if the game does not require some of these features, there's no harm in having the tools available in the engine. For example, parallax mapping could look nice on rooftiles or stone walls -- there's no reason to deprive the artists of that option. Anyway, I'll keep the thread updated as I go along.

Bumpity! http://i.imgur.com/dfoz3.jpg Edit: A Sobel-based map works much better http://i.imgur.com/R3U7r.jpg So far, I can add normal maps for models with a new <normal> tag in the "actor" description files. What you see in this example is object-space bump mapping, which has some very serious limitations compared to tangent-space mapping, but it's much easier to compute. Next step is tangent-space mapping.

I might give it a shot if I find the time. Parallax mapping would open a world of new possibilities for the art team!

That could be fixed by reducing the overbrightness/sun colour values in Atlas. Anyway, since we're on the topic of fancy shaders, perhaps a different solution to add more texture to the terrain could be to add bump maps so things don't get shaded so evenly. I see code for materials that use shaders, but I still haven't found if there's a system for loading extra normal maps, specular maps, etc. Maybe one of the programmers could point me to the right functions/documentation if they exist.

The units do have shadows, they're just hard to see when zoomed out this far. Yes, it would certainly be possible to have such effects (at least in GLSL mode)! Ideally, there would be a postprocessing filter manager that gets its instructions straight from map files/scripts to load specific effects and their parameters. I'm not too familiar with the codebase and how easy it would be to add a new manager type, but most of the heavy-lifting parts are definitely already there.

Wraitii, the high-contrast effect is due to the fake HDR, which is half-necessary for the bloom effect. I could reduce it, but I kind of like it this way Anyway, the halos were easy to fix once I stopped being lazy. People suggesting not to render on the terrain were onto the right track, and there's actually no need for an extra buffer: the models can be rendered first, then have the effect applied, then render everything else with depth testing on. New example: http://imgur.com/Tfa1b

Hey everyone, I've been coding some very rough GLSL post-processing tests just to see what they'd look like in 0ad, and thought I might share some results. The following images are in pairs, with the "plain" images first and the filtered images after: http://imgur.com/a/zZe2L These images use SSAO, HDR and Bloom filters. The dark halos around the character models are due to the SSAO, which otherwise looks pretty decent. Credit where it's due: the shaders are modified versions of the fantastic work of user martinsh on the Blender Artists forums. Peace Myc