myconid

It may bleeding edge, but it should still be reasonably usable - as was Alpha 10, for that matter. What you are describing shouldn't ever happen on a stable system... Check you have the latest drivers, check the game is linking to the right drivers, check your opengl is working correctly (as opposed to software emulation).

Could it be using the C compiler to compile C++? I guess that could cause linker errors like those. Other than that, I have no idea. To be thorough, close your terminal and re-open it, to get rid of any weird variables. Then clean-workspaces, update-workspaces and start over.

Some odd suggestions, though note I don't own a Mac so I have no idea what I'm talking about. Maybe the Mac equivalent of ldd would give you more useful information. Looks like this might be it: otool -vf /usr/local/lib/libpng.dylib Just to see how many versions of the library you have, this may or may not help: locate libpng.dylib On Linux this would give you a clue about what ld is thinking: ldconfig -v | grep libpng It appears on Mac you can force the package manager to install all versions of a library with the +universal flag. Finally, there's this:

I think that means you're linking a 64-bit binary to a 32-bit library. Have your package manager install the 64-bit libpng and it should work.

Probably not too difficult to implement, but creating new terrain textures in that format will be a huge PITA. There are simpler techniques that get pretty good results without the sweat and tears. See this article about the Unreal engine for some ideas. You should use the VHQ code only through the "conditional_define" statements and enable/disable it through the config. Is that what you did? Still, those rocks really do rock! What I was trying to say there is, if you wanted to process all the meshes in the "structural" directory, you'd need to use Windows' file search to separate the models that contain the word "Y_UP" from those that contain "Z_UP". It has to do with some models that were exported from 3DS with a setting that Blender can't import, so they need to be converted by the script. If you're exporting your rock models directly from Blender, then you don't need to worry about that (set handedness to False). Oh, one more thing: If you want to change the AO settings before you run the script, you need to comment out the last line (add # at the front). Then run Blender with the script, change the settings, open Blender's Python console and paste in the line line you commented earlier.

Ok, so now we know it's definitely a driver issue. Also, the "draw_vbo" function call means this is VBO-related as I suspected. You might want to try testing the configuration that works for you with "novbo = true", just to see what happens. And try this on Windows with a different driver when you get the chance, just to make sure this is indeed the driver's fault. Not much else we can do right now, I'm afraid. I'll check the memory alignment in the renderers over the weekend and push any changes to git, as that could help a bit (doubt it). Thanks for your patience, FeXoR.

Oh sorry, you need to type "r" to run it.

As long as materialmgr.quality is zero, GLSL shouldn't need tangents, but won't try to do anything fancy (I should have asked you to try that earlier). It's really strange that the supposedly "stable" ARB mode doesn't work for you, yet GLSL mode does. For a stacktrace, pick the options that make the game crash and then run the game with gdb gdb --args ./pyrogenesis -editor Once it crashes, type in "bt" and copy the result.

That's the issue with parallax on smoothed surfaces we were discussing on the previous page. Either disable parallax through the material (since you aren't using it, anyway), or do what Enrique was suggesting.

Thanks for following up. Do you still get that crash? A stacktrace would be nice.

Bring up the Javascript console and type in renderer.shadowZBias = 0.01 You'll notice that the shadow positions improve, but you get z-fighting artefacts on vertical slopes (e.g. I can see them in Oasis 10, on the hills). This is odd, as I've seen other shadowmapping implementations that use <0.005 without issues. Not sure what's so different here...

Avoid deprecated fixed pipeline functions for GUI rendering.

Hmm. I think we already have most of the stuff on that site, but we might be able to dig something useful out of the water section.

Performance shouldn't be affected, even on older hardware. However, if we're talking about combining (I'm guessing) two 1024x1024 textures into a 2048x2048, it would waste twice as much memory as we need. As I doubt any buildings use everything from both textures, maybe we could duplicate just some elements to a third texture. Still kind of wasteful, but not as much. For now "automatically", with a Blender script. I'm itching to work on the "dynamically", because it sounds challenging! Look at the relevant file in art/actors. There's a <texture> entry with the name "normTex", pointing to an image file. The heightmap is stored in its alpha channel.

Is that absolutely necessary? Would it be too difficult to combine all the textures into one, like for the Romans? Or, create a couple more textures that are more specialised, so each building needs only one? Eventually yes, as it'll be much easier to have a script to do the work automatically. But for now, what I'm trying to do simply doesn't work on buildings that are in pieces, so it needs to be done manually. You might want to concentrate your efforts on those buildings. Also check out that git branch I linked to above, if you want to see what sorts of results I've had so far. Hehe nope, it's working as intended! We told it to draw pillows, so it's all good. The heightmap texture needs to be reworked to look less pillowy.

Duly noted. Animated things shouldn't have AO baked onto them, anyway.

I think someone changed those in the default config file by accident a few revisions back, so you should update your SVN. Make sure you set gentangents = false, smoothlos = false. I think that's what causes it to close.

The binaries in SVN should work, but you need to edit these lines in your configuration file: preferglsl = true gentangents = true smoothlos = true materialmgr.quality = 10.0

zoot, either that didn't work as expected, the filter makes no visual difference, or mipmaps simply aren't being created.

First try at rendering AO for all the buildings: https://github.com/m...id/0ad/tree/AOO The AO maps are in textures/skins/ao. I've only updated a handful of the actors to use the AO maps/materials, mostly some civil centres, fortresses and barracks. It looks like the Greek buildings are split into a bunch of props for some reason, so those need to be put back together manually before this can work. The Blender script is in source/tools/AOBaker. To use: Make two directories, Y_UP and Z_UP. Separate models which contain the word "Z_UP" into one directory - use the Windows search function, or this on Linux grep -L -Z -r 'Y_UP' . | xargs -0 -I{} mv {} Y_UP Make another two directories to store the generated models (with extra UVs) and textures. Edit the texdestdir and modeldestdir lines in the script to be the full paths to the directories you created. Set srcdir to either ".../Y_UP" or ".../Z_UP" (these are full paths). When baking "Z_UP" set the "handedness" value to "True", when baking "Y_UP" set it to "False". Run Blender with blender -P bakeAO.py Blender will start churning in the background and spitting model and image files in the directories you created. Wait a trillion years. Head death of the universe.

Well, try it and find out! These are the default values for kaiser, see what you can get out of it: <File pattern="*" format="dxt5" mipmap="true" filter="kaiser" kaiserwidth="3.0" kaiseralpha="4.0" kaiserstretch="1.0"/> Sounds like a good idea to clear your cache when you change this. Get a few comparison screenshots, keep an eye on performance. Maybe we can make a good case for changing the default.

It is. All the textures are loaded the same way, remember? Then again, maybe this has to do with how the textures are converted. I'll look into that later. Btw, AMD's control panel thingie has a slider for "mipmap quality" on mine. Maybe you can set that through the command line or through a config file somewhere?

Oops, I did miss your edit. I think this is a driver issue, or there might be a hardware limitation somewhere that isn't reported correctly. At the very least, we can tell the problem has been around a while, as it was also present in Alpha 10 (e.g. this screenshot). It clearly has gotten worse in the SVN version, though if it's indeed because of a faulty driver, the causes for that might be completely random. Using the SVN version and an unmodified config (i.e. ARB, no tangents): Is it true that this happens mostly on unit models? What do you see on a map with only buildings? What happens when you set silhouettes = false in the config? As for checking if this is a driver issue, would it be possible for you to test this with AMD's driver? Either the Windows version or an older fglrx version would do. I'll also check if there's any weird memory alignment in the units renderer, though I'm not too hopeful.

Thanks! Yup, I already figured that out. I think the problem might be that these models have armatures in them. But anyway, 400/408 models rendered fine, so this is going well. On pause until this stuff gets done. Put that down for Alpha 12.

I'm not sure I understood what the problem was, but I'm glad we have a solution. On a rather different note, today I got started on an AO-baking script for Blender. I'm managing to save extra UVs and batch-bake AO for almost all the meshes in the "structural" folder. The exceptions are propylaea.dae and some ships (?), which Blender can't import.