Wijitmaker
-
Posts
9.663 -
Joined
-
Last visited
-
Days Won
9
Posts posted by 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?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.
-
This literally took 5 minutes using Blender:
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.
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.
-
Nope. That's true for object-space mapping, however the thing I'll work on next should overcome that limitation.
Is this true? I never heard that normal maps can't be shared in different parts of the model without looking goofy. If this happens to be the case, then I do not know a feasible way to create normal maps for the existing content.
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
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.
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!
Parallax mapping would open a world of new possibilities for the art team!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?What do they call spies in the ancient times?
-
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.Funny you should say that - AoE3's developers tried to make its AI build walls, but didn't make it work flawlessly so it was removed.
-
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?
-
The way I'm leaning is to just edit the existing meshes to give us those additional body types we've been talking about, plus some added geometry here and there (sleeves, a better looking foot, the bottom of tunics, et cetera), giving us a body mesh of maybe 500 triangles, give or take.
Would you mind making me a task with the specifics of what you want? I'd like to assist.
-
Cool Philip - nice test method.
Both models have 30 bones (counting the implicit root bone). The low-res mesh has 121 blend matrices (the number of distinct combinations of bone weights). The high-res mesh has 30 (because it's using the buggy PMD exporter which only uses one bone per vertex).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.So... I don't think the 6656-tri mesh is obscenely high resolutionUnfortunately 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 treesso e.g. the metal parts of a soldier's texture could be marked as highly reflective and the cloth parts as non-reflective
, 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 attachedEDIT: Did you commit the files?
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.But I hadn't thought of editing the current mesh, so I guess we could try that. It will be easier to rig it too, if I'm not mistaken.
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?
-
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?
Post-processing effects test (SSAO/HDR/Bloom)
in Game Development & Technical Discussion
Posted
Very nice
I've got an old Nvidia card (GeForce 7950 GT) and I'd love to test it, but I think I need an .exe?