Engine features from artist POV

[Enrique]

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"/>

[historic_bruno]

- 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.

This is very easy to change, here is the current AO calculation in the model_common.fs shader:

vec3 ao = texture2D(aoTex, v_tex2).rrr;ao = mix(vec3(1.0), ao * 2.0, effectSettings.w);ambColor *= ao;

So it is interpolating between 1 and twice the AO value according to the effect parameters in the material. That result is then multiplied with the previously calculated ambient color. I think you could even open that shader in Notepad++ (even while the game is running) and experimentally modify those lines, e.g. taking out the "ao = mix(vec3(1.0), ao * 2.0, effectSettings.w);" line.

[wowgetoffyourcellphone]

Enrique, I think it good to get interest level from artists on each feature to see what could be potential priotiry. Because why have programmer spend time implementing XYZ Uber Mapping if no artist has interest of making art for that feature. Just an example. So it would be good if all the active aetists and modders throw their 2 rubles into the caldron and see what they are interested in working on. Take coordination too if you want good results with these new feature.

AO maps going to multiply is easy like Ben B say, so that can be done super quick (but will need adjustment of the many AO maps already in game). Other things like transparent palm tree leaves seem less important in an RTS (tho still cool to have). LOD system seems far and away the most useful to have but also seem like the most hard to implement. Someone must be ambitious and implement it. With LOD some interesting changes can be made with zoom feature definitely (zoom in would pan up and zoom out can pan down, stull like that, with minimal lag time due to artwork only optimized for 1 zoom).

Edited March 15, 2015 by wowgetoffyourcellphone

[Enrique]

This is very easy to change, here is the current AO calculation in the model_common.fs shader:

So it is interpolating between 1 and twice the AO value according to the effect parameters in the material. That result is then multiplied with the previously calculated ambient color. I think you could even open that shader in Notepad++ (even while the game is running) and experimentally modify those lines, e.g. taking out the "ao = mix(vec3(1.0), ao * 2.0, effectSettings.w);" line.

That's great Ben, I'll experiment with this.

Enrique, I think it good to get interest level from artists on each feature to see what could be potential priotiry. [...]

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.

[wraitii]

LOD system

This isn't too complicated, and I would even suggest a last "billboard" level of detail, but it does require some technical changes. Since instancing isn't showing too much promise, I might try LOD first and see if instancing helps after.

Up to 3 UV coordinates per model

     <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"/> 

This is kind of technical, but OpenGL supports far more than "tiling", such as "mirror", "mirror on X axis", "repeat", "clamp", and is probably a better option. I don't get what you mean by "blend" and "order".

The possibility to enable tiling for a texture

See above.

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:

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.

Reflection coordinates/map

http://wildfiregames.com/forum/index.php?showtopic=19650&p=304957

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).

AO factor that is calculated as multiplied mode

Done tomorrow if you want.

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)

Per-model or per actor basis? Also not sure why you'd want that.

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.

Not urgent in my opinion and probably annoying to code. I don't think we'd need that for a translucent shader. Maybe.

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:

I had never thought of that but it should actually be codable without too many tricks.

[Stan`]

Having this will be nice :

#2596 (Toggle for Advanced Options (AO Spec parallax, gpuskinning))

#1195 (New/Improved Animation System)

#2324 (Actor format Update)

#2679 (Garisonned units in Animated Meshes bug)

Maybe decide on

#2680 (Ao on animated meshes)

#1428 (Animated Textures)

I agree that LODS would be nice, for low end GPUs.

#1550 (Improve gate animation behavior)

+1 For all the rest of the list Enrique.

Also, I'd like to be able to set variants for biome.

ie :

<variant = "Snow"><textures><texture file = "structural/celt_struct_snow.png" type = "overlayTex"></textures>

And having an option in the scenario editor to define the biome that would write to the XML of the map, to define which overlay to use

(Blood, Dust, Crackling, Snow, Dirt)

Also something I really want is #131

This will be a huge rework, but I could add propproints everywhere to add fire particles.

My last wish refers to weather and day night cycle...

Edited March 15, 2015 by stanislas69

[Enrique]

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.

[Stan`]

Also http://trac.wildfiregames.com/ticket/1613#comment:11 is great, we'll have some nice warnings.

[historic_bruno]

Minor improvement: the engine now supports more types of PNGs including grayscale and indexed color, this can reduce our texture size in SVN. For example, ptol_struct_spec.png saved as grayscale would be 1.57MB instead of 2.47MB (it would be a waste to only commit this conversion though, so I don't recommend it, but for future modifications we might as well). It shouldn't make any difference for the releases since we convert all the textures to DDS anyway, but it's nicer for modders to not have to worry about what kind of PNG the game accepts

[Enrique]

Any objections on adding SSAO effect that was written by Myconid?

Reasons: 

- Lighting in general tends to be inclined towards brightness rather than darkness. SSAO would help to differentiate objects on high-brightness maps

- Beautiful effects like normal/spec are only visible when the texture is lighted, textures in shadowed area do not have any kind of enhacement. SSAO would bring more depth on shadowed areas.

- Our static pre-rendered AO approach for buildings is subtle (good thing) which won't make the addition of SSAO an overkill effect.

- Obviously, terrain will have AO, which now it doesn't have it.

- Implementation left units out of the AO calculation, so only static meshes would be the only ones affecting AO, avoiding halo artifacts around units.

- Every single game uses it nowadays.

 

Here's the link to the diff where the effect should be:

And the post where it is explained that units are left out the SSAO effect to avoid halos:

Shouldn't be hard to implement if it is already written, isn't it? 

It would just need to expose a pair of sliders for the strength of the effect like the other postproc effects and a option in options menu to enable/disable.

Thoughts?

[Lion.Kanzen]

A have question about implement this in the FB Fan page in Spanish.