Wijitmaker

FYI our balance today is $4,754.07 USD

Not to sound like a broken record, but... Looks great. Keep up the good work. Think also about building windows for those night scene maps. Reminiscent of that age of empires 3 screenshot that can't be replicated in the released version of the game.

Looks great, I hope my old video card handle it If not, maybe a good excuse to get an upgrade

Good input, I'm glad to see there is some desire for this from the fans. The original game design was intended to have logistic features. Seasons, fixed territories, stamina, and moral were all interwoven parts and pieces that were going to play into this. I liked that, not just because I was on the design team that developed the idea, but because think this would have added a level of depth and strategy that would have brought something unique to RTS games and differentiated 0 A.D. in another way from the "Age of" series of games. There are some remaining elements though, and you never know what Part II might bring

I'm probably two steps behind (as usual) but... what if a duplicate .dae model was generated on first run - for the sole purpose of using it's UV data for pre-computed AO. Then the engine could draw data from both .dae files and add that 2nd UV channel into a single .pmd for it's various rendering passes. Each pass could point to a different UV channel as needed?

That looks great! So are you guys are thinking that if you had a seperate set of UVs, you could leave the diffuse the way it is today and the second UVs would be used when rendering the SSAO pass? If there was only a way (maybe a script?) to automatically generate these SSAO models/textures in batches out of blender or maybe even Pyrogenesis.

I did some digging around and my memory failed me. It appears that mirroring UVs is only a problem when you are developing the normal map and baking the map. Once that is complete, you are ok it seems. Two good tuts I've came across are here: http://www.chrisalbe...p_Tutorial.html http://wiki.polycount.com/NormalMap I would like to do a demonstration of how this could affect some objects in the game. Looking forward to seeing your future work

Normal/Displacement maps would look great if applied to the existing low poly models. The model's UV maps would have to be reworked - unless a seperate UV mapping could be applied to them. The problem with our existing UV maps is that there is shared texture space. For example, on many and most all of the unit maps the leg and arm portion of the texture is shared by both the left and right. If I recall correctly this goofs up the normal maps. Every tri must have it's own portion of the UV map. The same story for buildings too. It's to bad that the models weren't set up this way already - but back in the day - when these models were first made, normal mapping wasn't even on the radar. I think the biggest benefit for the least cost would be terrain normal / displacement maps, followed by units, then followed by buildings (the bump mapping looks great on them - and the art team is going high poly on the static structures anyway, so I don't think there would be much benefit in displacement maps on most flat/rectangular buildlings) This capability would be awesome though. Modders who use the engine for different purposes as well as the WFG developers could really do a lot with this - both now and in the future

Awesome work man - I'm loving the results of what you are doing! Sure does, makes me wish I was able to be an artist again - I'm jealous.

Looks nice, did the units loose their shadows? Would it be possible to apply a post processing hue/saturation/color cast & temperature tweak? If the config could be saved to maps it would allow map makers to make winter scenes appear cold and dreary, dessert scenes to be hot and arid. Similar idea to post processing for movies that you see in films like gladiator.

Um... spies, or maybe... agent of espionage?

Awesome! Nice work Pureon

Awesome work on the wall system guys It is great to see this in action! One thought I had for your consideration - for building walls on uneven terrain, I would recommend that your wall and turret models extend deep into the -Z axis, so that they are 'sub terrain'. Sort of like what is done with the docks and their piers. Just make sure that your wall turrets are tall enough to account for the build able terrain slope variation - and I think this new wall system would look pretty sharp on hills For AI, I think you guys should consider using FeXoR's RMG script logic. Have the AI reserve a wall location at it's starting position at the start of the game, and when the AI deems it time - start raising it's walls. Or for something more dynamic, maybe establish a wall that is inset from boundaries of the border/territories. To make it easier for AI to build walls, maybe it would be a good idea to allow them to break game rules by destroying gaia objects/resources in laying it's walls.

Cool images! This reminds me of mod'ing AoK back in the days of sprites before 3D. You should check out this thread: http://www.wildfiregames.com/forum/index.php?showtopic=15503 If you could talk someone into getting you at toggle for an isometric mode view in the game or atlas editor - you should do some quick screen captures and you would be way ahead of starting from scratch. Like Erik mentioned - you should get into Atlas. Click those links in the table of contents.

On a side note (not to derail this topic) but is there plans to review the hardware that the player is working with and simply disallow configuration options that would cause the game to crash on their system? Along with that, is there plans to recommend system settings for users using all that data your collecting?

Would you mind making me a task with the specifics of what you want? I'd like to assist.

Cool Philip - nice test method. I was wondering if that might be an issue. I'll see if I can get you a .dae file that will properly weight the vertexes. That might change performance though wouldn't it? I guess we'll soon find out. I'm surprised the engine performed as well as it did. 6656 tris is absurdly high in comparison to RTS games from the past that I'm familiar with (AoM, AoE III, BfME, C&C) - and I freely admit I'm out of the loop these days with what current RTS games are doing. However, if pyrogensis could handle something between 390 tris and 6656 tris (there is a lot of purposeless geometry in that model that could be cut), and the art team sees a visual benefit vs. the cost of making the new models - then I say go for it.Unfortunately I haven't heard anything back from that Blender/Max artist I met a few weeks ago. So, I guess it is back on me to get that skeleton working in Blender.

Perhaps it could be planned so that the (RGB) channel would be reserved for a normal map and the (A) channel of this special new shader texture would be used as specular.

Cool, shiny trees , so you would probably have to do that with a separate image correct? In the typical soldier texture, the alpha is already being used for player color.

So, what did you guys find out in the testing? What did it do to frame rates when you displayed a bunch of of these high poly animated models to the screen? How different does the profile look at a standard view in comparison to the low poly models today?

No, it is in the zip file I attached Definitely easier to rig. The model you gave me would be difficult to work with in the leg region because the legs are close together and the envelopes require a bit of massaging to get just right so that they don't act oddly. It would be much easier too because you would be using a character that is starting in the same default pose position. Oh, and .obj files are easier to work with than .dae's to get back into 3dsmax

I had to hack this in, and it is crude. But it will serve well for testing. Here is your high poly model. I had to modify it to scale & position the arms and legs in the same default position as the default skeletons are today. I didn't take a lot of time doing it either. I also just exported a .pmd because I don't have the right version of max currently installed to give you a .dae file... but again it should work for testing purposes. Pop 100+ of these guys in the game with any of the humanoid animations and see what happens to performance. Also zoom out to a standard RTS zoom level and see if you are getting the meaningful visual difference in profile between the low poly dudes and the high poly dude that your looking for. To make this process easier on all of us... I'd suggest taking the default humanoid mesh and add/manipulate geometry to it vs. starting from scratch. Are you guys going to redo the UV mapping and planning to redo the hundreds of humanoid textures too? test.zip

Zip up your 3 levels of quality of your models and I'll roughly apply the standard skeleton to them for you guys for testing.

The count depends what your talking about... just the base model or a model with all the props and stuff?

What I'm attempting to help you with isn't going to stop you from making a new mesh. You can still do that. I'm trying to preserve the dude skeleton, so it saves you guys from remaking the 50 plus humanoid animations.