Enrique

Using what I learned while animating the rhino into good use...

They look great, I'm still not sure why they weren't commited. Barley and wheat, and use them as a randomization of farms. Or make them civ-specific if historically accurate... I'm not good with that.

Which were the arguments to not implement LordGood's farms in the game?

Someone, someday will eventually implement a FPS or third person camera to zoom into the troops. Just maybe

Yeah, and probably on a ponies mod!!! oh wait...

This tutorial/FAQ I just made may help understanding prop-points: http://wildfiregames.com/forum/index.php?showtopic=19739#entry305562

What is a prop-point? A prop-point is a specific point in a 3D space (basically a coordinate) with a specific name which is used to reference that specific spot within 0AD actors (structures' models, units, animals, even props) What are they used for? They're used to spawn an actor within another actor. Basically you load another model/unit/structure/prop of the game inside the model where the prop-point is. Examples: - In a structure, you can use a prop-point to have a fountain which is already in the game and place it within that structure. - In units, you can use prop-points to have different gear in different places like the head for helmets, in the hands for shields/weapons etc - In animals, you can use prop-points to spawn effects like dust in their feet when they're running or blood when they die. - In props, you can use it for randomization of the prop, like a helmet which can use different styles of feathers spawned at the prop-point location. Which are the benefits? There are many. Just saying that you can reference any existing prop/model in the game directly in a place within your model is quite powerful already. - Powerful recursive system - Easy set-up - Randomization capabilities - Memory saving (you don't need to store again the data of a model that is already in the game) How can I create them? In Blender3D: In blender these prop-points are made with "empties". An empty is just a point in space which stores the coordinates where it's located within the scene. No materials, no geometry, no lighting data. Just location and rotation. To create an empty in your model, just open the "add menu" with shift+space in the viewport and select "Empty" there will be a list with different empties types, but these are all the same, just different types of representations of it. Select your preferred type (the standard is "Plain Axes") and an empty will be created in the location of the 3D cursor. IMPORTANT NOTES: -It is obligatory that the name of these empties start with: "prop- " or "prop_ " -Examples: prop-fountain , prop-helmet, prop_flag-AND it is also obligatory that the empties are parented to the geometry of your model. To parent the empties to your model, (in object mode) select all your empties first, then your model and use the hotkey CTRL+P and they'll be parented to the geometry.-Finally, when exporting, select all your empties first, and you model last, and export as usual.How can I reference a prop-point inside an .xml actor? Props are defined in the .xml normally after the mesh has been defined. Here's an example of the persian stables, where the horses are propped by prop-points. Note that minheight and maxheight are OPTIONAL parameters used for anchoring the prop-point to the ground. Prop parameters: actor= the actor .xml that we want to spawn in that prop-point attachpoint= the name of the empty/prop-point that we created in the mesh WITHOUT the "prop-" or "prop_" prefix minheight/maxheight= These are optional parameters to determine the anchoring to the ground, the max and minimum height the prop will have when conforming to terrain. <?xml version="1.0" encoding="utf-8"?><actor version="1"> <castshadow/> <group> <variant frequency="100" name="Stables"> <mesh>structural/pers_stables.dae</mesh> <props> <prop actor="props/structures/decals/dirt_4x4.xml" attachpoint="root"/> <prop actor="props/structures/decals/celt_sb1_mud.xml" attachpoint="root"/> <prop actor="props/structures/persians/stable_horse_a.xml" attachpoint="horsea" minheight="-20" maxheight="1.7"/> <prop actor="props/structures/persians/stable_horse_b.xml" attachpoint="horseb" minheight="-20" maxheight="1.7"/> <prop actor="props/structures/persians/stable_horse_c.xml" attachpoint="horsec" minheight="-20" maxheight="1.7"/> </props> <textures> <texture file="structural/pers_struct.png" name="baseTex"/> [...]Prop-points in armatures When creating prop-points for meshes that are animated (in other words, when they have an armature/skeleton) the prop-points are created with bones. These bones doesn't need to have a vertexgroup in the mesh, but they're required to have a name with the prefix "prop-" or "prop_" just the same as when using empties.These bones also need to have a parent bone, which will inherit it's movement (location and rotation)Animating these bones would not have any effect when the animation is imported into the game.When defining prop-points on animated meshes, nothing changes. It is the same procedure as normal prop-points. Other useful tutorials in this forum: Import/export assets from Blender to 0AD and baking AOHow to export animations from Blender to 0ADLowpoly modelling tipsHow to create textures with Blender3DIt would be nice if Stan could post also some guidelines to create these prop-points called dummies in 3DSMAX in this thread too

That cathedral is awesome man ! I can see it can be benefited greatly by AO though.

Ontopic... rigged and on it's way.

With the new meshes, I made some additional prop-points to give a solution to it. However, instead of "undressing" or getting rid of the gear when carrying resources or gathering them, they will have their shields on their backs, and the weapons on their hip. It's not realistic from the point of view that nobody would carry all that weight while doing hard work, but from gameplay perspective it would be much easier to discern which type of unit is working when you need to select your troops to fight in an emergency. It's also more realistic in the way that the props don't "dissapear" when they are performing those tasks.

It's the called "black marble wall" found in several important carth structures of the era which represented high status and wealth. Nah, just kidding, thanks for pointing it out av93. Thankfully its an easy fix, I'll take a look at it when I get home

Very interesting an informative. Thank you for sharing Micket. The technique to remove hard shadows from the photo-scanning data blew my mind. Will finish the video tonight

Hey I missed this thread! Great model and great texture work!

Which was the source image file license? remember if it's cc-by-sa 3.0 we need to credit the original author.

Try it standing like it was in the old way.

That head movement. Remembers me of this Which reference did you use to make the animation? The references I've found shows the boar moving like this: rear left - front left - rear right - front right instead of opposite back/front legs at the same time, which looks weird/cartoony. Not two legs make a front step at the same time. Also at the end of the loop, you can detect the interpolation line to "ease out" making the motion to lower its speed before starting again.. Here's an example, notice the order of the feet in the steps:

All of them/noisier ones. As I said I'm not very familiar with the terrain textures, so I can't remember which ones need more attention right now.

This is kind of technical, but OpenGL supports far more than "tiling", such as "mirror", "mirror on X axis", "repeat", "clamp",I guess "repeat" is the same as tiling? if it's possible I think it's a good thing to add. Tiling + an extra UV coordinates for detail to break tiling leads to very nice results and texture space savings. I can't imagine a situation where I'd like to use "mirror" and "mirror on X axis". But that's maybe because I haven't see it on action yet. I don't get what you mean by "blend" and "order".See above.OK now I get what you mean... I think this should be handled in the material and the shader itself. You'd supply a "snowTex" and pass some sort of define "USE_SNOW" and it would load a custom shader. Perhaps for this we ought to multiply the number of shader files rather than just add techniques. It's up for discussion.Different blending types means different operations between textures, and their order is important, that's why I suggested to have an "order" value to specify which textures are below and which on top. I'd really prefer to have the freedom of choosing which textures to add to the diffuse without having to remember which shader should I define. The snow was an example, but it's just a base diffuse texture, and in top of that a texture which is all transparent except on the parts where we're going to use snow. Instead of snow it could be cracks, grunge, moss, decorative patterns.... you name it. I'm not sure what you mean here... There are actually three issues on reflections: what to reflect (skybox, environment map, real?), where to reflect and how (fresnel based or not). This could be added on top of the current shader code or in a separate file but that would need some reorganization (which I'd like to do anyway).I think just reflecting the skybox would be enough. It's a RTS and the camera being above is going to reflect the sky 99% of the time. It'd also save texture memory I guess? Where to reflect as I said on the thread that I linked, should be dictated by the alpha layer of the specmap. The how (fresnel based or not) decision I think is based on performance. Does using fresnel effect affect performance? if yes, then don't use it. If it doesn't, let's use a constant fresnel value for all reflections (there wouldn't be so many reflective objects in the game). AO multiplying... Done tomorrow if you want.I prefer to test this myself first and experiment with the results. Maybe Myconid had a reason to use this way. Specular intensity modifier - Per-model or per actor basis? Also not sure why you'd want that.Per actor basis. Several helmets and shields in the game are completely specular, without any specmap that says where is specular and where it isn't and how much intensity should have. This way we don't have control over how much specular to use, only "use specular in the whole mesh". That's the reasoning behind it.

I'm all in for change terrain textures to help game objects to stand out. I barely worked on terrain textures, that task was managed mainly by Mythos so I'm not very familiar with it (also I'm not into map-making yet). What I think is that we shouldn't scrap all textures because they're busy/noise, I'd rather add them in an "eyecandy" section or some sort, while the "main" terrain textures can get this improvement to stand out objects. Using this busy textures in small quantities shouldn't affect the gameplay and mapmakers can still benefit from them. Diversity is nice

That's great Ben, I'll experiment with this. Yeah I understand. The translucent shader is the last, the LOD is the first. They're already ordered in most-benefitial for the game . (In my humble opinion, that is ) And sure, I'd love to hear the rest of the artists and modders opinion about this and which features are more interested in. I will also point to tutorials on how to use the features if implemented and of course write/record my own for 0AD.

Answering Ben's post here http://wildfiregames.com/forum/index.php?showtopic=19684&p=304999 This is my wishlist for the engine even if it can't be implemented finally or things to look for Part2. Ask any questions for any of the parts in the post and I'll try to clarify or go more in depth for better understanding of what is being requested. - LOD system -Up to three levels should be enough (mabe even only two). There should be a distance between the camera and the model to switch between meshes. It would be nice to be able to override the global distance to customize how close the camera has to be to the model to switch to higher detail mesh. i.e. (inside the <variant>) <LOD detail="detailedactor.xml" medium="mediumdetailactor.xml" low="lowdetailactor.xml" distance="50,100"/> (distance overrides the default) - Up to 3 UV coordinates per model.Being able to specify which UVs a texture should use specifying the number of the slot of the UVcoordinate. Example: <texture file="textures/wall.png" name="baseTex" UV="1" blend="mix" order="1" tiling="no"/> <texture file="textures/wall_damage.png" name="baseTex" UV="2" blend="mix" order="2" tiling="yes"/> - The possibility to enable tiling for a texture.(not-tiling textures is only useful right now on trees, because it extends the transparent pixels on the texture used by the branches) Or maybe make it the default and use a tag instead when we want the texture to not tile. Example: <texture file="textures/bricks.png" name="baseTex" UV="2" blend="mix" order="2" tiling="yes"/> - Up to 3 (or maybe just 3 for diffuse component, 2 for normal component) textures per shader component:For diffuse and normal. Spec and AO being the exception. Each texture should have the possibility to use different blending modes: normal(or mix), add, soft_light, overlay, multiply, screen, burn.....The texture will have the "order" value which determines wich texture is in the bottom stack and which in the top (for the blending operations).This would allow cool things like adding almost transparent textures for snow, damaged buildings, detail maps for variation... lots of possibilities. Also being able to have 2 UV coordinates for diffuse and normalmaps and use them with overlay or soft light will make possible to have awesome detail even in first person view. Example: Transparent damage texture with cracks that will show on top of the Base diffuse texture:<texture file="textures/BaseTexture.png" name="baseTex" UV="2" blend="mix" order="1" tiling="no"/> <--- Base diffuse texture<texture file="textures/DamageTexture.png" name="baseTex" UV="2" blend="mix" order="2" tiling="yes"/> Normalmap of the damage texture added on top of the basic normalmap with soft_light blending mode:<texture file="textures/BaseTextureNormal.png" name="normTex" UV="2" blend="mix" order="1" tiling="no"/><texture file="textures/DamgeTextureNormal.png" name="normTex" UV="2" blend="soft_light" order="2" tiling="yes"/> - Reflection coordinates/map.Being able to set the alpha layer of the specmap as the intensity for the reflection. (wraitii's approach seems to be in the nice direction)http://wildfiregames.com/forum/index.php?showtopic=19650&p=304957 - AO factor that is calculated as multiplied mode!Right now I think it's overlayed?? The thing is that AO now needs a neutral grey where we don't want shadows, anything over mid-gray would make the model to be brighter than it should, and that's not very intuitive/useful. The common practice is to have a greyscale image, where the full white doesn't affect the texture at all, and full dark makes the texture almost black. -Being able to set the specularity intensity per-model basis.This would allow to increase/decrease the specularity intensity without having to alter the specmap and have control over objects with "full specularity" (those are objects that do not use a specmap to drive the intensity but have specular shader) - Double-sided geometry option per-model basis.This would come in handy with foliage meshes. A tag in the actor .xml would determine if it should render both sides of the triangles. Also would make possible a translucent shader. - Translucent shader.The fake and cheap (but good looking) way to fake subsurface scattering on leaves/flora. This normally uses an additional map which is normally a very bright and saturated diffuse which is shown at the opposite side of the face that is receivig direct light. This makes flora look much better when being lit and avoids hard contrast shadows when looking at non-lighted flora geometry planes (there is a nasty trick used now for farms that is make the flora to be less affected by shadows, but it looks weird in night-lighting maps) Example: <texture file="gaia/leaves_diffuse.png" name="baseTex" UV="2" blend="mix" order="2" tiling="no"/><texture file="gaia/leaves_translu.png" name="transTex" UV="2" blend="mix" order="2" tiling="no"/>

Looking pretty good! It could be slightly improved though, I'll be working on that a bit. Do you use A18 or the SVN version? For your latest post: it is certainly possible to code a new component that does that, I'm not too sure about existing ones. The alpha in the normalmap is already being use by the parallax effect. However the alpha of the specularity map is only used for self-illumination effect which is almost non-existent, and it needs a flag or a different material type to be enabled, so I think the alpha layer of the specmap would be perfect for this.

Hello Kicking_Bird, It's great all this theory of design, we'll put it in good use. However, the part that you seem to be missing it's the global picture, I'll explain: This project started among people who loved history. And one of its big focus was unsurprisingly, historical accuracy. While not focusing on selling a game to the masses, they designed the game that they wanted to play based on their design points (which were more than historical accuracy ofc) the fact that it is liked by many and have several fans is a plus and consecuence that they had a nice idea. Some will like it for their historical accuracy, some for the gameplay, etc. While it is very easy to find things to improve upon a specific model look, it is harder to find a solution which encompass the historical point of design in it. Let's take as example as you did the persian civilization. Have you researched how the buildings looked? have you tried to absorb which were their main characteristics to make an accurate model? Guess what, they were quite blocky: http://upload.wikimedia.org/wikipedia/commons/b/b5/Persepolis_vue_d'oiseau_Chipiez.jpg (copy and paste on the browser or it doesn't show in chrome) http://upload.wikimedia.org/wikipedia/commons/8/8c/2009-11-24_Persepolis_02.jpg http://www.cais-soas.com/CAIS/Images2/Achaemenid/Persepolis/PersepolisWallCollapsing4.JPG http://www.tourismplaceinfo.com/wp-content/uploads/2010/12/Persepolis-Iran-Attraction.jpg What you see on the current structure designs is based on the artists efforts to make a close representation of how the civilization would look. Sure it is easy to say, hey look! forgetting about history you can make the game follow better the principles of design!. While maintaining the game's design points and improve its visual read is a much harder task. Also, based on the game's design is the task of making each civilization to show traits of uniqueness between its set of structures, reflecting that they're part of a culture, which is unique to the rest of them in the game. Persians have blocky buildings, romans have a more delicate architectural feeling, mauryans had they curved roofing, etc. While we're looking for a different feeling for each civilization that reflect it's culture, we want to have similar layouts for the different type of buildings in the game. So the players know the function of the structure regardless of the civ they're playing. This improves readability a lot, and helps the artist to balance this with silhouette's readability. (And if I may add, your house design silhouette does not improve the problem you were pointing about current silhouettes, but I know it's a wip I'll wait until final) So yeah, we're not scrapping one of the design pillars of 0AD just because one (or 100 tbh) person think it's boring and we'll welcome anyone who wants to improve the game following its theme. TL;DR: Easy to make cooler models that the ones in the game if you scrap several game's design choices, Harder to make them following the game's design.

The best solution IMO is to set the colors for bushes, trees with food, etc (objects that the player can interact with) and more or less ban those values from terrain/tweak terrain values to not be the same as the collectable ones.

Gimp and blender