myconid
-
Posts
790 -
Joined
-
Last visited
-
Days Won
11
Posts posted by myconid
-
-
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.dylibJust to see how many versions of the library you have, this may or may not help:
locate libpng.dylibOn Linux this would give you a clue about what ld is thinking:
ldconfig -v | grep libpngIt appears on Mac you can force the package manager to install all versions of a library with the +universal flag.
Finally, there's this:
It is unsupported to have software installed in /usr/local while using MacPorts because of interference like this. Please remove or rename /usr/local, "sudo port clean hatari", and then try again. -
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.
-
Myconid, how hard does this look to you? Specifically the technique described in the GPU Gems article?
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.
Added VHQ Parallax for the Rocks!
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!
BTW Myconid, could you explain to me the step 1 of the Blender's script of automatic AO Generation?
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 -editorOnce it crashes, type in "bt" and copy the result.
-
My feeble attempt at the Iberian buildings, using your AO maps.
The CC has a few artifacts though, I'll commit so you can have a look.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.
-
The current bias is a fixed value of 0.02. Again, not sure, but reducing it to 0.01 may make the problem less noticeable and/or create artifacts changing it.
Bring up the Javascript console and type in
renderer.shadowZBias = 0.01You'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.
- Avoid deprecated fixed pipeline functions for GUI rendering.
-
Zaggy found this neat resource: http://www.gamerendering.com/
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.
-
If we combine them, the map will be bigger, like 2048x2048.. Not sure if it'll affect the performance, but that's the way we did in RoTE
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.
In the future can we hope for Dynamically and automatically generated AO?
For now "automatically", with a Blender script. I'm itching to work on the "dynamically", because it sounds challenging!
If I may know, which file is the heightmap for that part? I know it's because the file is generated using software instead of handmade.
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.
-
The props use different texture files for different bits of the buildings, so they can't be joined.
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?
Btw, are you going to replace the AO I've already done?
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.
I'm pretty sure the tiles on top didn't intended to look like pillows. I don't know if it's only in my laptop though.
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.
-
Word of caution here: even if you seem to be able to import a rigged/skeletal/armature model, you shouldn't, because the Blender importer will mess up the bone transforms which won't be noticed until they are imported back into the game. Unless the importer problem has been solved in a new version of Blender but I haven't heard that it is yet. They should be excluded from the conversion process. This would include animated siege units and ships.
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.
-
To enable this effect, am I required to build a new one or is it automatically enabled when I update the SVN?
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.
- 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
-
It would seem that the Kaiser filter is a decent improvement over the box filter. I wouldn't know why people here haven't chosen to use it by default, though?
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.
-
From http://trac.wildfire...i/TextureFormat:
I wonder if this is done for normal maps? If not, it would seem a factor in degrading normal map quality when zoomed out.
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.
-
I'll try to explain.
Thanks!
The problem is probably that Blender doesn't like the DAEs having materials in them. Delete <library_images>, <library_materials>, <library_effects>, and near the bottom of the file, delete <instance_material>.
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.
Sounds good. How are things like bloom and distance fog coming along?
On pause until this stuff gets done. Put that down for Alpha 12.
-
Confirmed, flat faces with smooth shading may cause that problems. Can't commit now, I'm in a hurry, but if Zaggy reads this, he can make a list where he finds this artifacts to fix them setting the faces to "flat"
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.
Building on OS X from SVN Source
in Game Development & Technical Discussion
Posted
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).